iOS開発における最強のパッケージ管理方法 - Qiita
この記事では私が最強だと思っているiOS開発におけるパッケージ管理方法を紹介します。 ここで言うパッケージ管理とは、我々がアプリやライブラリを開発する際において、 依存する外部ライブラリを宣言、取得、ビルド、共有等をすることです。 最強の方法 この記事で紹介する最強の方法は、「Carthage --no-build --use-submodules + xcworkspace」方式です。 その名の通り、Carthageを--no-build --use-submodulesオプションと共に使用しつつ、xcworkspaceを使います。 以下ではその詳細について述べます。 そもそもパッケージ管理とは何か 我々がパッケージ管理に求めている事は何でしょうか。 私は大きなところでは下記だと整理しています。 依存するライブラリのバージョンを宣言・共有できる事 依存ツリーをフラット化して解決できる事
[Swift] @_exportedの挙動調査 - Qiita
├── Main │ └── Main.swift ├── SubModule │ ├── SubModule1.swift │ └── SubModule2.swift └── SubSubModule └── SubSubModule.swift 同一モジュール内への影響調査 SubModule1.swiftにて、@_exported import SubSubModuleを記述する。 ファイルをまたいでSubModule2.swiftでもSubSubModule.swiftのAPIが利用できる。 ├── Main │ └── Main.swift ├── SubModule │ ├── SubModule1.swift // @_exported import SubSubModuleを記述 │ └── SubModule2.swift // SubSubMo
![[Swift] @_exportedの挙動調査 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/9546c1df19dd3d952fdd46d890b7522a40c92977/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-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCU3dpZnQlNUQlMjAlNDBfZXhwb3J0ZWQlRTMlODElQUUlRTYlOEMlOTklRTUlOEIlOTUlRTglQUElQkYlRTYlOUYlQkImdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWYyODYwY2Q3NjcxNTY5YmJkYmU3NzVhZjRmNzNiYmEw%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzaHRua2dtJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0xM2U1YTg4YTI1ZmMyNmIyYzJhM2EzMTAwNGZkZjg1ZQ%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gWWFob28h44OH44OZ44Ot44OD44OR44O844ON44OD44OI44Ov44O844Kv%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D9f89440a5188a1185f5b94dfe5eec793)
Auto Layoutの静的な制約で実現するカラム幅が可変のテーブル - 24/7 twenty-four seven
次に示すような見出しと各カラムが右寄せ、ラベルの文字数によってカラムの幅が伸縮し、広くなった場合は隣の列を押し出し、短くなった場合は少なくとも見出しの幅に収まり、各列の間には一定のマージンを置くというテーブルレイアウトを、静的なAuto Layoutの制約だけで作ることを考えます。 このような、UIコンポーネントが持つコンテンツの大きさによって隣接するコンポーネントを押し出すような場面ではAuto Layoutがとても効果的に働きます。 Auto Layoutなしで実現しようとすると、列ごとの各行の文字幅を計算し、最大の幅に合わせて再配置する、という処理をコンテンツが変わるたびに行うということになりますが、Auto Layoutの制約を使用する場合ではそもそもレイアウトの再計算を自分でやる必要はないので、コンテンツの変わったタイミングなどを気にする必要はありません。 ただデータを再代入する
Auto Layoutの静的な制約で実現する伸び縮みするヘッダービュー - 24/7 twenty-four seven
TL;DR, 優先度の異なる複数の制約を同時に定義することで、静的な定義だけで動的な振る舞いを実現できる 動的な要素の少ない構造のビューはより堅牢である はじめに 読みやすくメンテナンスしやすいソフトウェアを作るために重要なことの一つは構造をシンプルに保つことです。 iOSアプリのビューは壊れやすいソフトウェアの代表ですが、できるだけシンプルに作ることで変化に強い、堅牢で壊れにくいソフトウェアにできます。 動的な要素が少ないということは、ビューがシンプルであるということの指標の１つと言えます。 この記事では下記に示すような、スクロールに合わせて伸び縮みするヘッダーを、動的な要素を無くし、Auto Layoutの静的な制約のみで実現する方法を解説します。 動的な要素とは、実行時におけるビューおよび制約の追加・削除、Frameや制約を更新することと、機種やスクリーンサイズ、標準UIコンポーネン
iOSプロジェクトのBuildを高速化する | CyberAgent Developers Blog
はじめに AWAという音楽ストリーミングサービスでiOSエンジニアをやっている小梛です。 AWAでは、Build時間が長いことによる開発効率の低下が定期的に問題になっており、高速化のためにさまざまな試行錯誤を重ねてきました。 その概要については、昨年末CA.swiftというiOS勉強会において「Build時間改善」というタイトルでLTさせていただきました。 ただ、このLTから既に半年が経過し、Xcodeのアップデートもあったことで、一部挙動が変わっていたりします。 本記事では、最新データを再調査した上で、LTでは伝えきれなかった詳細部分についても含めてBuild高速化についてご紹介できればと思います。 目次 調査環境 Build時間の計測方法 Build設定の最適化 コードベースのCompile時間削減 Buildマシンの性能を上げる まとめ 調査環境 macOS Sierra / Xco
海外展開を目指すアプリで実装したセキュアで高速な画像配信の話 / Image distribution for overseas
iOSDC Japan 2018発表資料です。
iOS-factor
iOS-factor was inspired by the famous twelve-factor app framework, a methodology to write high-quality web services. iOS-factor uses the same structure and similar principles, re-written and applied to the iOS app development processes. Background Over the past 10 years, the iOS development process has shifted drastically: from supporting a single device to a wide range of available iOS-powered iP
iOS-factor
iOS-factor は高品質の Web サービスを作成するための方法論である twelve-factor app framework にインスパイアされました。iOS-factor は同じ構造とよく似た原則を使い、それらは iOS アプリ開発プロセスに書き換えて適用されています。 背景 ここ10年で iOS アプリ開発のプロセスは劇的に変わりました。 1つのデバイスのサポートから iOS 対応の iPhone や iPad など多種多様なデバイスと tvOS や watchOS のようなさまざまなプラットフォームのサポートへ git のサブモジュールとしての手動追加から依存関係マネージャーの利用へ 大部分がローカルのデバイス上で実行される iOS アプリからバックエンドサービスに大きく依存するアプリへ iOS アプリのレビューが2週間以上から1日以内へ iTunes を使った iPhon
Swift 3 以降の NotificationCenter の正しい使い方 - Qiita
Swift 3 で NotificationCenter(旧 NSNotificationCenter ) がせっかく改良されたのに、そのメリットが活かされないようなコード例をよく見かけるので、正しい使い方をまとめます。 以下、主にSwift 2時代のコードを3でどうベターに書けるようになったのかという視点メインでの記述となっています。 次の class を用意して、それをもとに説明していきます(struct は自身を登録できないので class で説明)。 class NotificationObserver { func addObserver() { // A: ここに NotificationCenter 通知登録処理を書く } func removeObserver() { // B: ここに NotificationCenter 通知解除処理を書く } /** C: 今回、通知
iOS9以降では "NotificationCenter.default.removeObserver(_:name:object:)" をdeinitに書かなくても良いですよ。 - 文字っぽいの。
表題通り。間違ってたら教えて欲しい。 iOS9以降をDeployment Targetにしている場合のみの話ですので、iOS8系をサポートしている場合は今まで通り明示的にremoveしましょう。 今までは NotificationCenter.default.addObserver(_:selector:name:object:) して追加されたNotificationを、明示的にremoveする必要がありました。用途によりますが、 viewWillDisappear や deinit の中で NotificationCenter.default.removeObserver(self) とか書いていることと存じます。 この処理がiOS9以降を対象としたビルドでは不要になりました。 ほんまかいなという話ですが、addObserver(_:selector:name:object:) - N
Twitter での6年間 #1｜Satoshi Nakagawa
2012年1月、Twitter の iOS チームに7人目のエンジニアとして入った。 たまたま最初の週が Hackweek だったので、通常の仕事は一旦停止。なんでもやりたいことをやっていいらしい。入ったばかりで何もわからない状態だったので、ぼくのメンターのテックリードがやっていた Twitter for Mac の多言語化を手伝うことにした。水曜にパッチをマージしてもらって、ぼくの担当部分は完了。その後は次週から始まる通常営業に備えてコードを読み始めた。 次の週からは通常のサイクルが始まった。毎朝スタンドアップミーティングがあり、各自の仕事の進み具合を他のメンバーと共有する。前職までは同僚がほぼ日本人ばかりだったので英語で仕事をしたことがなく、聞き取りがうまくできなかったのを覚えている。 この日からさっそく Twitter for iOS のユーザーとして気になっていた問題を直し始めた。
アプリのユニットテストについて初歩から考えてみる/ABC UnitTest
2017/10/02 俺コン Vol.1 / Day.1
iOS嵌ったメモ - Qiita
残しておかないと二度嵌りそうな実装のメモ。 もっといい解決方法があれば教えてください。 随時更新しますので、内容が変わります。 エラーログがでなくなった、謎のエラーがでるようになった iOSシュミレーターを切り替えたりしていると、シュミレーター側にゴミが残るのかいろいろ不具合が発生する。 iOSシュミレーターを選択 ツールバーのiOSシュミレーターを選択 コンテンツと設定をリセットを選択 リセットボタンを選択 これでアプリを起動し直すといろいろ解決したりする。 スクロールしないUIWebViewを使用したい UIWebViewのスクロールをNOにして使用する場合に困るのが高さの通知です。 オブザーバー等で無理やり高さの通知を行うと、無限ループする可能性があるので、JavaScriptから一方的に高さを通知して、UIWebViewの高さを広げる方法がいいと思います。 <html> <body
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Faster iOS performance debugging with ETTrace
How To Get Your App Featured on the App Store
Building a Trello Like iOS App with Drag & Drop API — Alfian Losari
GitHub - SCENEE/FloatingPanel: A clean and easy-to-use floating panel UI component for iOS
ゆめみのカレンダー | Advent Calendar 2017 - Qiita
Nakaji Kohkiさんのツイート: "ARで髪の毛を染めた時の色を試せるアプリやってみたんだけど、めちゃめちゃ精度が高くてすごい。 リアルタイムに動かせるし、髪の毛の境界もくっきりしてるので近づけても全然違和感がない。髪染める時はこれ使って確認すれば失敗しなくてよさそう〜 https://t.co/fy2nYhPZcp… https://t.co/29FHDl9drA"
GitHub - onmyway133/awesome-ios-architecture: :japanese_castle: Better ways to structure iOS apps
