アプリが依存している Swift Package ライブラリのライセンスを一覧表示するためにライブラリを作りました - Cybozu Inside Out | サイボウズエンジニアのブログ
はじめに こんにちは、モバイルエンジニアの中村（@Kyomesuke）です。 私が担当している kintone のモバイルアプリ（iOS）では、現在脱レガシーを目指して幾つかの課題に取り組んでいます。 その一つとして、パッケージマネージャーを CocoaPods から Swift Package Manager に移行するリファクタリングに挑戦していたのですが、この移行に際して一つ課題がありました。 kintone モバイルやサイボウズ Office 新着通知アプリなど、サイボウズのモバイルアプリには依存している外部ライブラリのライセンスを一覧表示する画面があるのですが、これまでその機能をAcknowListというライブラリを使用して実現していました。 しかし AcknowList は CocoaPods にしか対応していないため、Swift Package Manager に対応するため
大規模なマルチモジュール開発をSwiftPackageに移行して運用してみた - Timee Product Team Blog
はじめまして、iOSエンジニアの阿久津 @sky_83325 です。 タイミーでは、機能ごとにEmbedded Frameworkに分割して開発するマルチモジュール開発に取り組んでいます。 現在では、本体AppやAppExtensionの他に7つの共通Framework、そして16個の機能Frameworkという規模になってきました。 今回は、そのマルチモジュール開発をEmbedded Frameworkではなく、Swift Packageを利用した方法に乗り換えてみたので、その成果や学びについて共有できればと思います。 取り組んだ経緯・背景 タイミーでは、技術顧問の@d_dateさんと隔週で「ツバメの会」という情報共有の場を設けています。そこでは、直近タイミーで取り組んでいることの共有や相談をしたり、SwiftやiOS、その他エンジニアリングの最近の話題について議論したりしています。 そ
CIでのiOSアプリ依存パッケージビルド時間を削減する - stmn tech blog
mohamed HassanによるPixabayからの画像 こんにちは、スタメンでモバイルアプリ開発を担当している @temoki です。 2月に Mobile Act ONLINE #3 というオンライン勉強会に参加し、iOSパッケージマネージャー奮闘記 というテーマで発表しました（詳しくは以下のスライドをご覧ください）。 この発表でお話しした内容の背景にあるのは CIでのiOSアプリビルド時間を短縮したい ということです。CIサービスは実行時間が利用料金に関連しますし、何よりユニットテストやアプリのテスト配信などの待ち時間は極力減らしたいですよね。 弊社のiOSアプリのビルド時間に大きく影響しているのは Firebase iOS SDK などの依存パッケージのビルドです。そこでこの記事では。依存パッケージの導入方法の工夫により、CIでのビルド時間を削減する過程をお話ししようと思います。
Swift Concurrency チートシート
Swift 5.5 で Swift に Concurrency （並行処理）関連の言語機能が追加されました。これによって、 Swift で非同期処理・並行処理のコードをより簡潔かつ安全に書くことができるようになります。 しかし、 Swift Concurrency は Structured Concurrency や Actor など、多くの人にとって馴染みが薄いだろうと思われる概念を含みます。具体例を通して効率よく Swift Concurrency を習得できるように、本記事では iOS アプリを題材に、 Swift Concurrency 導入以前（ Before ）と導入後（ After ）のコードを比較することで、何がどのように変わるのかを紹介します。 なお、 Swift Concurrency 関連の機能は次の三つに大別できるため、本記事の Before & After の例も
iOS13ではStoryboardでもDIができる件について - Qiita
iOS13未満での実装方法の詳細については以下の記事で説明しています。 Qiita - iOSとコードベースレイアウト 勿論、プロパティインジェクションならばiOS12以下でもStoryboardで定義したUIViewControllerで可能ですが、initializerでのDIをする設計にすることで以下の恩恵が得られます。 DIする値をプロパティで保持する場合に、varでなくletで定義できるのでより安全 DIする値をプロパティで保持する場合に、Optional型でなく非Optional型で定義できるので無駄なUnwrapが不要 UIViewControllerの生成を行うために、必ずDIが必要になるので、プロパティインジェクションのように設定忘れが起こり得ない iOS13でStoryboardでイニシャライザでDIする iOS13では地味にこんなAPIが加わっています。 instan
WWDC21：Apple、カメラ機能の提供の仕方を刷新 | NEWS | Mac OTAKARA
最短撮影距離とは、レンズからシャープなピントが得られる最も近い点までの距離のことで、iPhoneのカメラにも最短撮影距離がありますが、これまで公表されていませんでした。 iOS 15からは、iPhoneのオートフォーカスカメラの特性として、最短撮影距離が公開されます。 iPhone 12 ProとiPhone 12 Pro Maxの広角カメラには顕著な違いがあり、Proでは最短距離が12cmであるのに対し、Pro Maxでは15cmでフォーカスしています。 これは、iPhone 12 Pro Maxに搭載されているセンサーシフト方式の手ぶれ補正技術によるもので、同様に、望遠カメラの最短撮影距離は、12 Proよりも12 Pro Maxの方が遠くなっています。 これは、望遠レンズの到達距離が長くなったことによるものです。2倍ズームに対して2.5倍ズームになっています。 iOS 15の新機能と
SwiftPMのCI向けキャッシュを考える - Qiita
はじめに Firebase iOS SDK も Swift Package Manager (SwiftPM) サポートがβリリースされたので、CocoaPods や Carthage を剥がして SwiftPM に集約していきたいですよね。 そこで重要になるのが CI でのキャッシュです。Firebase iOS SDK は非常に大きなパッケージで、インストールやビルドに多くの時間を費やしてしまいます。なので、できる限りキャッシュしてCIのビルド時間を短縮することを検討しました。 結論としては「現時点でビルド時間の大幅な短縮には至らない」となったのですが、ここに至るまでに調べたり試した内容をまとめます。 従来のパッケージマネージャーの場合 まずは SwiftPM 以前のパッケージマネージャーである CocoaPods と Carthage についてのキャッシュについて要点を整理します。
Swift Package Manager and How to Cache It with CI | Uptech
Swift package manager is a dependency manager developed by Apple to simplify the development process. Integrated into Xcode 11, it became a turning point in the world of dependency managers for Swift based projects. With no need to install additional software tools it serves as a user friendly, fast working iOS package manager. Below, we look at how the Fastlane tool can be used for task automatio
Introducing Twitter Text Editor
Twitter Text Editor is a standalone, flexible API that provides a full-featured rich text editor for iOS applications. We use this for Tweet composers on Twitter for iOS. Today we’re happy to share Twitter Text Editor so iOS developers outside Twitter can add robust text editing to their applications. Why Twitter Text Editor? Text editing is one of those common tasks in iOS applications which look
なぜiOSのMVVMはdisられるのか — Elm Architectureとの比較記事から考える
iOSアプリではMVVMが多用されている。UIKitとFRPライブラリであるRxSwiftを組み合わせて実装されるのが一般的である。（私はReactiveSwiftの方が好きだけど…） MVVMはマイクロソフトのWPFで考案されたソフトウェアアーキテクチャパターンで、それがiOSに導入されて広まった。 しかししばしばiOSにおけるMVVMは批判の的となってきた。もっとも俎上に上がるのはVMの肥大化・複雑化である。最近では以下の記事があげられる。 なぜ MVVM は Elm Architecture に勝てないのか この記事を元になぜMVVMが批判されるのかを見ていこうと思う。 ViewModelは複雑化する論上記記事ではやはり「複雑化しすぎたViewModel」と主張している。 複雑化したコードが掲載されているので全文は転載しないが、主要な個所を見てみる。 まずViewModelの状態の管
なぜiPhone 11 Pro では0.5の線が描画できないのか調べてみた - Qiita
環境 Xcode 11.3 何が起こったのか いつもどおり 0.5 の線を引くために Storyboard の AutoLayout で Height = 0.5 の制約を指定した。 すると、デザイナーから「線の太さにばらつきがあるので揃えてほしい」と指摘があった。 ↑たしかによく見ると上の線のほうが若干濃くも見える・・。両方とも 0.5 で指定しているが、念のため次のコードを書いて height を出力してみた。 print(separator1.frame.size.height) // 上の線 print(separator2.frame.size.height) // 下の線 と出力された！ 目の錯覚ではなく、たしかに上の線のほうが濃いことがわかった。 なぜ0.5で指定しているのに正しく描画されないか Twitter にてこの疑問をつぶやいてみたところ、 @kishikawakat
UIView Auto Layout life cycle
Auto Layout is among the most important topics when it comes to iOS development in general. It is extremely important to understand Auto Layout life cycle to save time and avoid naive mistakes. Lack of this information will sooner or later lead to UI glitches and performance issues in your app. This article consolidates information about the steps that every UIView with Auto Layout enabled undergo
なぜ IBAction に didTapButton という名前をつけてはいけないのか - Qiita
私はこういうコードが本当に好きじゃない。私が気に入らないのはアクションメソッドの名前、具体的には didTap の部分だ。 didTapSaveButton や didHitSend 、 cancelButtonTapped なんていうのも同じだ。私はこれらに違和感を覚える。そこには主な理由が2つある。 Target-ActionはDelegateパターンではなくCommandパターンである Guides and Sample Code に隠れているAppleの開発者向けドキュメントの奥深くに、あなたは Model-View-Controller (MVC) パターンについての記事 を見つけられるだろう。そこでは、オリジナルのMVCパターンはCompositeパターン と Strategyパターン 、 Observerパターンから成り立っており、AppleのMVCパターンには左記に加えてM
[iOS] 複数のUIWindowの挙動を確認する | DevelopersIO
1 はじめに UIWindowとは、特別なUIViewでありビュー階層のルートとなるものです。 通常のアプリ作成では、実装の対象は、このウィンドウに載せられたUIViewControllerが主であり、ウインドウ自体は、テンプレート任せとなっているのであまり意識されていないと思います。 テンプレートから生成されるコードでは、AppDelegateクラスに、次のような１つのUIWindowを保持するプロパティが設定されています。 #import <UIKit/UIKit.h> @interface AppDelegate : UIResponder <UIApplicationDelegate> @property (strong, nonatomic) UIWindow *window; @end しかし、このUIWindowは、アプリに１つではありません。 下記のコードで、アプリのウイン
![[iOS] 複数のUIWindowの挙動を確認する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/cd616d43627770acf3d2af18695851272d60bed9/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F12%2Fios.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Xcode version 13.2 & 13.2.1 在iOS12上 由libswift_Concurrency.dylib 引起的crash修复 - 掘金
iOS 处理 navigationBar.titleTextAttributes 属性时机(Swift)
iOSDC Japan 2021
30 Auto Layout Best Practices for Xcode 10 Storyboards and iOS 12
GitHub - tnmendes/watt: iOS App for TP-Link Devices (Kasa Smart & Tapo) | Support page for issues related to Watt iOS App
Demystifying iOS Layout