Appleの新しいUI構築フレームワーク「SwiftUI」を学ぶための教材まとめ #WWDC19 | DevelopersIO
SwiftUI はWWDC 2019のキーノートで発表された iOS/MacアプリなどのUIを構築するためのフレームワーク です。デベロッパーフレンドリーなコーディング＆直感的なデザインツールの組み合わせで、超簡単にUIを構築できる特長があります。例えばこんな感じです。 import SwiftUI struct ContentView: View { var body: some View { Text("Turtle Rock") .font(.title) .color(.green) } } struct ContentView_Preview: PreviewProvider { static var previews: some View { ContentView() } } これまで以上に簡単にUIが構築できることから、発表後iOSエンジニア界隈ではバズワードになっています
Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita
これは Swift Tweets の発表をまとめたものです（次回開催はこちら）。イベントのスポンサーとして Qiita に許可をいただいた上で投稿しています。 ありがとうございました！Q&Aは他の人の発表中でも構わないのでリプを飛ばして下さい。 続いては僕 @koher の発表で、タイトルは "Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい" です。 #swtws — koher (@koher) 2017年1月14日 第 1 部: Swift の 4 種類のエラーについて あまり知られてませんが、エラー処理について、 Swift 2.0 設計時に Core Team がまとめた "Error Handling Rationale and Proposal" というドキュメントがあります。このドキュメントは、僕が去年 try! Swift で発表した際にも参考文献にしまし
Swiftのエラーハンドリングはなぜ最先端なのか - Qiita
Swiftのエラーハンドリングは他のメジャーなプログラミング言語のどれとも異なる新しい仕様を持っています。特に、検査例外を持っているのですが、これはJavaで採用された以降はほとんどの言語で採用されていないため、現代では否定されている過去の間違いだったと広く認識されていると思います。そのため、Swiftユーザーで無い人は、検査例外という言葉をみた瞬間に興味を失ってしまうため、その詳細がなかなか世の中に伝わっていないと感じています。一方、私はこんなSwiftのエラーハンドリングをとても気に入っていて、様々な言語の進化の歴史を踏まえた産まれた最も優れた最先端の仕様だと思っています。この記事ではその考えを説明します。 Javaのエラーハンドリング Javaは検査例外を持っています。これにより、あるメソッドがエラーを送出するかどうかを関数のシグネチャとして静的に表明できます。 // 検査例外の例
ssd -- Socket Server demo by Apple · GitHub
ssd.c 0���U �T��U // Copyright (C) 2010 Apple Inc. All Rights Reserved. #include <launch.h> #include <libkern/OSAtomic.h> #include <vproc.h> #include "shared.h" static bool g_is_managed = false; static bool g_accepting_requests = true; static dispatch_source_t g_timer_source = NULL; /* OSAtomic*() requires signed quantities. */ static int32_t g_transaction_count = 0; int server_check_in(void) { in
SwiftでTCPサーバーを作ってみる - Qiita
Swiftでは，Cの構造体でさえもExtensionでどんどん拡張できてしまうのは愉快痛快ですね． C言語でのソケット関連のお約束をSwiftで拡張して使いやすくしてみようという試みです． Cの，というかソケットAPIでは， struct sockaddr_in sin; memset(&sin, 0, sizeof(sin)); sin.sin_len = sizeof(sin); sin.sin_family = AF_INET; sin.sin_port = htons(0); sin.sin_addr.s_addr= INADDR_ANY; bind(sock, (struct sockaddr *)&sin, sizeof(sin)) ... という感じでsockaddr_inからsockaddrへキャストするのがお約束．swiftではこれをストレートに表現できないので，Exte
CotEditor を Swift に移行する - Qiita
本稿は Swift Tweets 2017 Summer で発表（ツイート）したものをまとめ、Qiita 用に追記・再構成1したものです。 発表概要 CotEditor プロジェクトの現主催者 1024jp です。CotEditor は昨年 2016 年に Objective-C から Swift に移行しました。今日はその話をします。 本発表は、事前に以下のような概要を開示していました。 2004 年から脈々と受け継がれる総 Cocoa 製の macOS 用テキストエディタ CotEditor は、昨年 2016 年に Objective-C から Swift に 100% 移行しました。 Swift は魅力的な言語ですが、すでに Objective-C で 10 年超動いてるアプリケーションを誰に頼まれたわけでもないのにわざわざ Swift で書き直す意味は果たしてあるのでしょうか？
Swift3のIUO(!)型から属性への変更に考えさせられたこと - Qiita
Swiftを初めてそろそろ半年くらいですが、未だに書き方のベストプラクティスを模索する毎日です。 今回もベストプラクティスがわからないケースがあったのでその一つについて書きたいと思います。 内容はOptionalと初期値についてです。 まず確認 Optionalとは Optionalとは通常の型に加え、nilも入れられる型です。 使用するときは!をつけてアンラップする必要があります。
Pattern Matching, Part 4: if case, guard case, for case
Pattern Matching, Part 4: if case, guard case, for case May 16, 2016 Updated: Oct 17, 2016 7 minute read — Also available in: 🇨🇳 Chinese Now that we’ve revisited the various syntaxes for pattern matching in part 1, part 2 and part 3, let’s finish this blog post series with some advanced syntax using if case let, for case where and all! Let’s use what we saw in previous articles and apply them al
[Swift] CocoaPodsとCarthageの違い / ライブラリ管理 - Qiita
どちらでもSwiftを扱えるようになりつつある今 Cocoa関係のライブラリの依存管理としてはCocoaPodsがデファクトな状態でしたが、11月に新しいライブラリ依存管理システムのCarthageが登場しました。その時点ではCocoaPodsがまだSwift対応（ダイナミックフレームワーク対応)が遅れていたこともあり、各記事が盛り上がったり、対応してるSwiftライブラリも見かけるようになりました。 が、CocoaPodsもSwift対応の0.36 betaがクリスマスにリリースされ、どちらでもSwiftのライブラリが扱える状態が整いつつあります。 そんな状況で、それぞれの違いやできることについてザッと調べてるのですがCarthageのREADMEのDifferences between Carthage and CocoaPodsの項が参考になった＆面白かったので翻訳して載せておきます
![[Swift] CocoaPodsとCarthageの違い / ライブラリ管理 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/4d3e2fb125ebbc9eddb763db40e16e729d22d3f1/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCU3dpZnQlNUQlMjBDb2NvYVBvZHMlRTMlODElQThDYXJ0aGFnZSVFMyU4MSVBRSVFOSU4MSU5NSVFMyU4MSU4NCUyMCUyRiUyMCVFMyU4MyVBOSVFMyU4MiVBNCVFMyU4MyU5NiVFMyU4MyVBOSVFMyU4MyVBQSVFNyVBRSVBMSVFNyU5MCU4NiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MjdmNjJiZGQ5MWVmZjViMDA1MGIxN2MwZDA3MDI4NjY%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbm9yaTA2MjAmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWUzYTk0YTc1MGY5NzFkOGQ4NWY4NjQ2YWQxZjk1NjM3%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Dbb155f3041eb1872b5dc71cdf4160112)
Server-Side Swift is here: it's Perfect
What is Perfect? Perfect is a web server and toolkit for developers using the Swift programming language to build applications and other REST services. It lets developers build using only Swift to program both the client-facing and server-side of their projects. It’s the ideal backbone for cloud and mobile technologies. Developers can be more productive and efficient using Perfect to write less co
SwiftのToll-Free Bridgeの実装を読む - Qiita
Toll-Free Bridgeとは Objective-CにはToll-Free Bridgeという仕組みがありました。 これは、C言語のライブラリであるCoreFoundationと、 Objective-CのライブラリであるFoundationの間で、 対応するクラス同士でバイナリ互換性があり、 ポインタを強制キャストすることでどちらにもなる、という不思議なものです。 下記にNSDataをCFDataとして扱うサンプルを示します。 // コンパイル: clang -framework Foundation a.m #import <Foundation/Foundation.h> int main(int argc, char * argv[]) { @autoreleasepool { NSData * data = [[NSData alloc] initWithBytes: "
Swiftを使ってモダンなWeb APIクライアントを爆速で開発する - Qiita
iOS Advent Calendarの13日目を担当します@giginetです。 APIクライアントを作りたいなあと言う気概になったので、APIクライアントをライブラリ化するまでの方法をご紹介します。 なお、この記事は執筆時点の最新の環境で検証しています。 Xcode7.2 Swift 2.1.1 Carthage 0.11.0 今回使用するAPI 今回は、APIクライアントが見当たらなかったので、WakaTimeという、エディタからデータを送り、自分のプログラミングについてのデータを集積してくれるサービスのAPIクライアントを作って、自分の1週間のコーディングを管理できるようにしてみました。 完全自動で、自分のプログラミング「作業ログ」を収集して可視化する「WakaTime」が素晴らしい件！ | シェアしたくなる最新のWebサービス・ITニュース情報をチェック！ APPGIGA!!（ア
Swiftは結局どうオープンソースになったのか？ - なるようになるかも
オープンソース化ばんざーい！！とかそういうのは全然興味ないです、ごめんなさい。 XCode7で何気なくimport Foundationなどをすると、ついでに以下のライブラリがリンクされるそーです。 SwiftCore（Swiftのコア言語仕様） Darwin（UNIXベースのOSX/iOSの基盤部分。CoreFoundationもここに含まれる） Dispatch（Grand Central Dispatch） CoreGraphics（描画処理の基盤部分。今はOpenGLだと思いますがそのうち中身がMetalになるのでしょうね） ObjectiveC（Objective-Cランタイム関数） Security Swiftがオープンソース化される、と言っても本当にpure Swiftのコンパイラだけが提供されてもあまり意味がないので、「どこまでがどうオープンソースになるのか？」というのが興
Markdown in Swift - Justin Duke
Nov 30, 2014 Markdown in Swift A thought process I had last week: Man, it would be great if I could write descriptions for Barback in Markdown. Wait, maybe I can. There are Markdown compilers for everything, right? Wait, what would it even compile to? HTML? An NSAttributedString? How would that work? Blargh. Let’s just Google things and hope for the best. But for you, reader dearest, I have compil
vagrantup.jp - vagrantup リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
Swift 2.0 の try, catch ファーストインプレッション - Qiita
WWDC 2015 で Swift 2.0 が発表されました。オープンソース化などのうれしいニュースでも盛り上がっていますが、言語仕様としては try, throw, catch が導入されるという大きな変更がありました。本投稿は、 The Swift Programming Language の新章 Error Handling を読み、多少のコードを書いた上での個人的な感想です。 結論から言うと、 try, catch の導入は良い変更だと思えないけど、 try, catch を導入する前提なら考え得る限りベストに近い仕様だった、って感じです。 よかったのは、 ErrorType は enum タイプセーフなエラー情報 エラー処理が強制されている（検査例外のような形） try! でエラーを無視できる あたりです。個人的には、 try, catch でなく Either 的なものを公式サ
Swift - また言語仕様が変わっていやがる 2015春 - euphonictechnologies’s diary
You have been warned! Swiftは開発途上の言語です というわけで、またSwiftの言語仕様がガラリと変わりまして、さっぱりビルドを通りません。ぱっと見ると17個ものビルドエラー。なーんかC->C++->Ocamlあがりの私としては言語仕様というのはバックワーズコンパチブルでなんぼやというところなのですが、Swiftはそうではないようです。未来の開発者がクリーンな言語仕様で働けるようにがしがし後方互換性を殺すというのはまあ、いいのかも。 ですが、私はいましこしこビルドエラーを直さないといけないので、晒しておこうと思います。 変わったところ as of 9 Apr 2015 オーバーフロー演算子のうち(&%)がなくなったっぽい まあ、当たり前なんですが、&%がなくなりました。オーバーフローモジュロというのは意味わからないからだと思いますが、直交性のない演算子の組み合わせ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fast and Reliable Swift APIs with gRPC
Binding/Listening to a port in Mac OSX Lion 10.7.2 fails
GitHub - vapor/vapor: 💧 A server-side Swift HTTP web framework.
