LT枠なので自分だけゆるい発表になりましたが、他の発表は良い物ばかりでした https://iosdc.jp/2016/

2016/8/15更新 汎用性高めのExtension集です。後半にライブラリもまとめました。 Swift2.2で確認済みです。 紹介している全てのextensionを導入したリポジトリを公開しています（紹介していないものも含みます）。 詳しくは下記をご覧ください。 iOSアプリをハッカソンで作るときに便利な初期プロジェクトを作ってみた Swift3版はこちらです。 クラス名の取得 extension NSObject { class var className: String { return String(self) } var className: String { return self.dynamicType.className } }

こんにちは。Airシリーズ開発チームでiOSの開発リードを担当している永井です。 この度、Airレジから予約台帳機能を切り出して、Airレジとレストランボードの2つのアプリとして新たに5/10にリリースしました。 iPad版・iPhone版合わせて181,175行あったAirレジですが、今回内部的にもObjective-CからSwiftに全面的に書き換えています。 まだまだリファクタリングしていきたい課題はありますが、コード行数は70%も減り（つまり元々の行数から30%になりました）、SonarQubeで示される技術的負債も500dから21dに減り、かなり成功したと言って良いのではないかと思っています。 今回の取り組みの中で、良かったこと・再検討したいことがいろいろ発見できました。それらについてまとめてみるので、これからSwift採用を検討している方々の参考になれば幸いです。 取り組みのポ

2017/10/15 更新 とりあえず、入れておくと便利なXcodeのプラグインをまとめてみました。 汎用性のあるものを重視して、厳選しています。 プラグイン初心者向けに有名なものも含まれています。 主に Swift 向けです。 Xcode7.3.1 (一部 Xcode9.0) で動作確認しています。 Xcode 9.0で動作確認済みのものには 、Xcode8.3で動作確認済みのものには を付けています。 Xcode 9 / 8 2017/10/15追記 Xcode9や8でこれらのプラグインを使用するためには、各プラグインにUUIDを追加する必要があります。 追加を一括で行ってくれるツールがこちらです。 インストールして、実行後、Xcodeを再起動することで、Alcatrazを含むいくつかのプラグインが使用可能になります。 環境にもよりますが、プラグインのインストール後、Xcodeを起動す

はじめに 近々リリース申請に出そうと思っている新作アプリでReSwiftとRealmを使ったのですが結構相性がいいなと思ったので基本的な考え方と少し躓いたところなどを共有したいと思います。 ReSwiftって？ Realmはもちろん有名なので先人の素晴らしい記事に解説をまかせるとしてReSwiftについて簡単に説明したいと思います。 ReSwiftはReduxというJavaScriptのフレームワークをSwiftで実装したものです。ReSwiftやReduxは以下の四つの要素で成り立っています。 View ... iOSアプリだとViewControllerに対応、画面に表示する部分 Action ... アプリ内で行われる処理。ただしこれ単体ではなにもしない State(Store) ... アプリの状態を保持/表現するもの Reducer ... 現在のStateとActionを受け取

殿堂入り Realm Core Dataなんて最後に使ったのはいつだろうか。。。 Alamofire SwiftyJSON 通信ライブラリAlamofireのブロック構文に、JSONをより扱いやすくするSwiftyJSONをぶっこむ。 最近SwiftyJSONの仕様が変わってイマイチになったが、Swiftバージョン2.0でguard構文が追加されるので、guardで宣言するときに使いやすくなるかも。 SDWebImage みんな知ってる画像キャッシュライブラリ。 UI paper switch スイッチのON/OFFで色をアニメーション付きで変更する。 SCLAlertView フラットなアラート LTMorphingLabel 文字をモーフィング(アニメーション)させる MMPopLabel ポップラベル。Slackの立ちあげ時とかに出てくるアプリケーションのチュートリアルとかに使う。(

以下は書籍「Advanced Swift」のSwiftコーディング規約の部分を翻訳したものです。原文はオンラインプレビューで公開されています。 Advanced Swift - Swift Style Guide この本を書くとき、そして私たちのプロジェクトでSwiftのコードを書くとき、以下のルールに従うようにしています。 可読性が最も重要です。これには簡潔性が助けになります。 関数には常にドキュメントとしてのコメントをつけましょう。ジェネリクスを使うものは特に。 型は大文字で始め（UpperCaseLetters）、関数と変数は小文字で始めます（lowerCaseLetters）。 型推論を使いましょう。型が明らかなのに明示的に書くことは可読性を損ないます。 曖昧さがある場合や規約を定義する場合は型推論を使わないようにしましょう。（例えばfuncが明示的な戻り値の型を持つのはこれが理由

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

はじめに 僕がプログラム（プロダクト）を作る際に注意していることのメモで僕自身の設計時の方針がイマイチ決まってなかったのでここにメモとして残す。 前回はRailsの場合なども入れてしまったのでまとまりが悪くなったので今回はSwiftにフォーカスを当てる。 なお、Swiftのバージョンは1.2です。 僕が次に作るアプリで気をつけようと思う事をつらつらメモっていきます。 変数の定義について 変数の定義は悩ましいのですが、Objective-cの時代に沿った命名を使います。 定数 定数は基本的にlet宣言の大文字 class API { // APIを使用するか？ static let USE_FLG = true // class let USE_FLG = true // この定義でも可能で好みで使えば良いと思う。僕はstaticを好む。 } 定数のみの場合はクラスではなく構造体でも定義でき

前回の記事「iOS アプリの構造がどのようになっているか紐解いてみる」で iOS アプリの構造について説明しました。深いところの説明ばかりだったのでもう少し浅いところ、画面の見た目や画面遷移を実装する方法について説明します。 ユーザの要望がどのようにアプリに反映されるのか アプリができる背景には「アプリでこんなことしたい」というユーザの要望とか、開発者自身の「アプリを通してXXのような素晴らしい体験をユーザに提供したい」という思いが出発点になっています。 ユーザの要望だったり開発者の思いは「UX設計」「ユースケース抽出」「UI設計」という3つの段階に分けてアプリに反映していきます。図にすると以下のような感じです。 UX(ユーザエクスペリエンス)設計 ユーザの要望や開発者のこんなもの作りたいという思いを元に、いつ、どこで、誰が使うのか？アプリが使われる状況を洗い出す。その上でユーザがアプリを

はじめに Xcode6とswiftに慣れる練習課題として書いています。 UINavigationContollerの制御は、戻るボタン（leftButton）を使わない場合の方が珍しいはずです。 segue、actionをstoryboardで設定する方法 NavigationContollerのカスタム化によるsegue利用時のfuncの呼ばれ方の確認 segue内でのアニメーション指定 以上をつらつらと書いてみました。 長文になってしまいましたが、どなたかの参考になれば幸いです。 8/28 Xcode6β5でコードが変わっていたところを修正しています。 9/8 Xcode6β7でコードが変わっていたところを修正しています。 9/28 Xcode6.0.1でコードが変わっていたところを修正しています。 10/20 Xcode6.1でprintlnで使用しているNSDateのclass構成

いろんなツールがあって技術選択に迷うので、定点観測的にいま思っていることをざっくり書いてみました。 TL;DR ひたすらスピードを求められるプロトタイピングなどはCordova（Ionicなど含む） Cordova上でReactで開発した資産を引き継ぎたいみたいな前提があってユーザーレスポンスを改善するならReact Native 時間がかかってもいいからとにかく安定させたいならネイティブ 学習コストが高くてもよくて開発スピードと安定性を両立するならXamarin 私はネイティブが一番好きです。 はじめに 「AndroidとiOSアプリを両方作ってくれ」という要件はよくある話ですが、ベンチャーで新しいサービスをモリモリと立ち上げている中での両対応となると、両方共ネイティブで作っていくわけにはいかないこともあります。 そもそもそんなにバランス良くAndroidエンジニアとiOSエンジニアは集

Issue #1 Lighter View Controllers, June 2013 By Chris Eidhof view controllerはiOSプロジェクトの中で一番大きいファイルになりがちで、必要以上に多くのコードを含んでいることが多い。ほぼ決まってView Controllerはコードの中で最も再利用性の低い部分だ。View Controllerをスリムにし、再利用可能にして、より適切な場所にコードを移すテクニックを見ていこう。 この記事のサンプルプロジェクトがGitHubにあるので参照されたい。 データソースとその他のプロトコルを外に出す View Controllerスリム化の最も強力なテクニックのひとつが、UITableViewDataSourceの部分を独立したクラスに移すことだ。これを2回以上やってみるとパターンが見えてきて、このための再利用可能なクラスを作る

Swift2系の解説本もほぼ出そろったようなので個人的に独断と偏見で比較記事を書いてみようかと思います。 Swift 開発歴は去年の4月ぐらい *1 。もともとプログラミング経験のある理系院卒の人間ですが、 iOS 開発者としてはペーペーの部類です。 前置き 基本的にプログラミング未経験者向けの内容と思しき部分は読み飛ばしたうえでのレビューです。特に最近発売されたものについては アプリ作成経験ありの状態 *2 での感想です。しかも 上から目線 です。 よって著者の方はお読みになられないほうが良いと思います。 紹介する書籍について 予算の関係上、一部の書籍のみ紹介します *3 。 「 詳解 Swift 改訂版 」などの文法オンリー系、逆引き系、特定トピックに特化した系統の書籍については対象外です *4 。 また、超初心者向けも私自身が対象読者層と外れるので同じく対象外としています。 自分で改

Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.

About the content This talk was delivered live in March 2017 at try! Swift Tokyo. The video was recorded, produced, and transcribed by Realm, and is published here with the permission of the conference organizers. Don Norman’s "The Design of Everyday Things" is a classic design book, focused on the design of physical objects. Many of the principles that he discusses are also applicable to non-phys

自分が iOS アプリケーションを作るとき使いまわそうと思った，テンプレ的な設定とかをまとめておく． やりたいこと やることは以下． ディレクトリ構成をきれいにする MVCアーキテクチャに対応させる Storyboard を削除する segue とかで画面遷移させたり，一つの storyboard に複数の view controller が対応しているのは管理しづらくなりそうかな，と思ったので UI 整形に xib ファイルを使う UIView を各画面ごとに作成し，対応した xib ファイルを UI 整形用に使う 0. 環境 Xcode7.2 Swift2.0 OS X Yosemite 1. ディレクトリ構成をきれいにする iOS アプリケーションは MVC アーキテクチャに則っているので，対応したディレクトリ構成にする．File > New > Project から Single

これからiOSの開発を始める新人プログラマーさんたちに向けて僕が知っている範囲で大変恐縮ですが、OSS活動やQiita、Blog、Twitter、勉強会、執筆などアウトプットされている方を中心に集めてみました。 ここでご紹介させて頂いたエンジニアはほんのごく一部で、もっともっとたくさんの素晴らしい活動をされている方々がいらっしゃいます。紹介しきれず、本当にごめんなさい。m(_ _)m 各エンジニアのQiitaやBlogの記事を読んだり、OSSへのコントリビュートの活動を見たり、開発されているOSSをコードリーディングすることで視野が広がり、きっと成長の糧になることと思います。また先人の方々の活動のように、ご自身が今後学ばれた知見をアウトプットし、コミュニティで活動されると嬉しく思います。 記事やOSSをリンクまとめにせずエンジニア（人）を軸に紹介しています。誰が書いたり作ったりしているのか