はじめに 問題点 ベンチマークテスト(Sampleコードで実演) 計測方法 パターン1: Identifiableに適合したデータのリスト表示 ベンチマークスコア パターン2: リスト内ボタンの表示 ベンチマークスコア ベンチマーク結果 問題発覚と調査 解決方法 改善とその結果 パターン3: UIViewControllerRepresentableを利用したリスト表示 パターン4: 従来通りのUIKitのUITableViewを利用したリスト ベンチマーク結果 改善の結果 総括 We are hiring! N予備校春の入学無料キャンペーンのお知らせ はじめに こんにちは。N予備校iOSアプリ開発チームです。 以前、N予備校iOSアプリへ SwiftUI を導入するまでの道のりについてという記事を書かせていただきました。今回は導入しSwiftUI化を一部の画面で行った結果、どうなったかを

N予備校iOSアプリ開発チームのyoppieです。 筆者のN予備校での経歴は Androidアプリ開発チーム 2021年4月 - 2022年3月 iOSアプリ開発チーム 2022年4月 - 現在 です。iOSアプリ開発にチャレンジしたくなり、Androidアプリ開発からiOSアプリ開発に移りましたが、iOSアプリ開発とAndroidアプリ開発(以下I/A)でのさまざまな違いがあり、苦労しました。(iOSアプリ開発チームに移り10ヶ月経ちますが、今も苦労しています...) I/Aでのさまざまな違いがありますが、この記事では筆者が特に違いを感じた点をまとめています。 I/Aどちらかのエンジニアの方がもう一方に移りたて、もしくは移ろうか迷っている方に向けた記事となっています。 IDEに関連した各種バージョン 一般的にXcodeでiOSアプリ開発を行い、Android StudioでAndroid

はじめに 導入に向けて検討したこと 流れ 1. UIKit 及び Storyboard をどのように置き換えるのか 2. 書き慣れた MVVM パターンを維持できるのかどうか 3. 既存のプロジェクト構成でもスムーズに導入できるのか 4. アプリのサポートOSが iOS14.0+ だが、 SwiftUI 特有の苦しみは問題なさそうか 5. 本当に開発効率は向上できるのか 導入決定後から本格対応までにやったこと 流れ 1. 画面構成がシンプルで、利用頻度の低い設定画面の SwiftUI 化 2. チーム勉強会の時間を使って一緒に学習 実践 移行計画 成果 おわりに We are hiring! はじめに N予備校 iOS アプリ 開発チームでは、長い間 UIKit & Storyboard & RxSwift & MVVM で開発してきました。 以前から「Storyboard やめたい！」「

AppleがiOS 16やwatchOS 9のリリースに合わせて「Human Interface Guidelines」をアップデートしています。詳細は以下から。 Appleは現地時間2022年09月07日に開催したスペシャルイベントの中で、プロの冒険家やアスリート向けにApple Watch史上最も耐久性のある「Apple Watch Ultra」と、TrueDepthカメラのDynamic Islandが特徴的な「iPhone 14 Pro/Pro Max」を発表、12日には「iOS 16」と「watchOS 9」を正式にリリースしましたが、 AppleのDesign Evangelism Managerを務めるMike Sternさんは16日、アプリケーション開発のベースとなる「Human Interface Guidelines(以下、HIG)」をアップデートし、新たにiOS 16

こんにちは、EC事業部事業領域拡大チーム所属のTatsumi0000です！業務ではAndroidアプリ開発をメインに、時々iOSアプリの開発をしています。 EC事業部では、Chapterという活動をしています。Chapterとは、事業部内のチームを横断した組織で、フロントエンド、バックエンド、セキュリティなど、様々なChapterが存在しています（詳細については、後述します）。その中でも私はセキュリティChapterに参加し、Chapterのメンバーと一緒にいろいろな活動をしてきました。 この記事では、EC事業部で行っているChapterと、セキュリティChapterの活動の一環として、mobsfscanをgithub.comのGitHub Actionsで試した話について紹介します。 EC事業部のChapterとは mobsfscanをGitHub Actionsで試した おわりに EC

WWDC22 Recap in Goodpatch WWDC22の発表内容とHIGの更新内容の振り返りつつ、AppleプラットフォームにおけるHIGの位置付けとソフトウェアUIデザインへの向き合い方を考えます。

こんにちは、クライアントエンジニアのちぎら（@_naru_jpn）です。Apple が Swift Concurrency への移行をサポートするためのサンプルプロジェクト Updating an App to Use Swift Concurrency を公開しているのをご存知でしょうか。 このプロジェクトには、DispatchQueue を用いて記述されたアプリのコードと、それを Actor などの Swift Concurrency を使用したコードに書き換えたアプリのコードの 2 つが同梱されています。運用しているプロダクトのコードを書き換えるのは規模も大きく大変ですが、小さいプロジェクトから書き換えの課題感を掴んだり、ウォーミングアップとして Apple のサンプルプロジェクトから学べることがあるだろうという事から、このプロジェクトを題材にして社内勉強会を開催しました。 勉強会の

Swift 5.5 の目玉は Concurrency （並行処理）関連の言語機能の追加です。 Swift 5.5 には Concurrency 以外にも細々としたアップデートはありますが、本トークでは Concurrency にフォーカスして紹介します。

過去に公開されたXcodeをダウンロード＆インストールできるXcodeのバージョン管理ユーティリティ「XcodeUpdates」がリリースされています。詳細は以下から。 Appleの統合開発環境Xcodeは、最新バージョンこそMac App Storeからダウンロード＆インストールできますが、macOSやSwiftのバージョンの関係で過去に公開された古いバージョンのXcodeを利用したい場合、Appleの開発者ポータルサイトへログインし、古いXcodeを検索してダウンロードしなければなりませんが、そんな過去に公開したXcodeの検索からインストールまでを行うことができるXcode管理ユーティリティ「XcodeUpdates」がリリースされています。 SwiftUI implementation of xcodes by RobotsAndPencils Project supports m

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

Flutter vs React Native vs Native: Deep Performance Comparison The Story Behind the Research As a custom software development company, inVerita and its mobile development team continuously dig into the performance of cross-platform mobile solutions available on the market, that’s how Flutter vs React Native vs Native Part I emerged. Yes, it was quite controversial as one can state we weren’t using

はじめに これは2020年3月4日付けで変更された App Store 審査ガイドラインの翻訳&差分ガイドです。 前回からの主な変更点は、プッシュ通知の広告利用や飽和カテゴリの更新などです。これまでプッシュ通知の広告利用は禁止されていましたが、条件付きで認める方針に変更されました。App Store で飽和しているカテゴリには、占いや出会い系が加わり、該当アプリの審査は厳しくなるようです。 multi-player から multiplayer への変更など、軽微な変更は修正項目から除外しています。 修正の撤回 1.4.4 と 5.1.5 について、改訂翌日に変更が無かったことにされているため、改訂当日に確認した方は注意が必要です。 急遽撤回されただけなのか、明示しない方針に変えたのか、真意は不明ですが、少なくとも文書上では 1.4.4 と 5.1.5 は変更無し、が正です。 本記事では「

こんにちは。メルペイのiOSチームの@kenmazです。 メルペイのiOSチームでは Xcode11 で導入された Xcode Previews 機能を用いて、UIKitベースのプロジェクトの開発効率向上に取り組んでいます。Xcode PreviewsといえばSwiftUI用の開発支援機能、というイメージがありますが、実は従来のUIKitベースのプロジェクトに対しても使用が可能です。 Xcode Previews を使うことでiOS Simualtor等を起動することなく、様々な状態のビューをリアルタイムにプレビューできるため、開発効率が大幅に向上します。 またXcode Previewsが提供する強力なプレビュー機能を使うことで、Interface Builderの支援も不要となったため、従来のxib/Storyboardを用いたビューの実装から、コードによるビューの実装への移行を試みる

Swiftにおけるインポートとリンクの仕組みを探る iOSDC 2019

更新情報 2019/08/28: 初版公開 2020/11/25: 各項目について現在の状況を追記 ⚓ はじめに こんにちは、主にiOSアプリの開発を担当している川島と申します。 iOS 13のリリースが間近に迫りつつあり、またWWDC2019ではSwiftUIを始めとした新しいツール等の発表、ARKit2やCombineフレームワークなどの発表などにより、昨今のiOS界隈が盛り上がりを見せています。 そうした新しいツールや技術が登場する反面、Appleはバッサリとした互換切りや新技術への対応を短期間で強いる傾向にあり、既存プロジェクトの保守などをしているiOSアプリエンジニアはこの時期に頭を悩ませる人が多いのではないでしょうか。 2年前のSafeArea対応なんかは記憶に新しいですね。 今年もそうした「〇〇対応が必須」のような情報はチラホラと聞きますが、断片的な情報が多い印象です。 この

Xcodeは使用していると開発速度向上を目的としたキャッシュデータを大量に蓄積していきます。開発をしているとそのようなデータを消したくなる時があります。 Xcodeは〜/ Developerフォルダにキャッシュファイルやシンボルを格納していきます。 ディレクトリの場所は決まっているので手動かスクリプトで削除することが多いと思います。今日iOSやFlutterの情報を発信しておられる@_monoさんがそのような内部データをGUIで削除できるアプリケーションを紹介しておられました。 素晴らしいツールを手に入れた(　´･‿･｀) > There’s a great tool called DevCleaner which will easily delete up to 20GB of unused data for you. This is how it looked for me after

Swift 5.1 で Opaque Result Type (SE-0244) が導入されます。 Opaque Result Type とは何でしょうか。例を見てみましょう。次のような Animal と Cat があるとします。 protocol Animal { func foo() } struct Cat: Animal { func foo() { print("cat") } } some という新しい言語機能を導入しなくても、 -> some Animal の代わりに -> Cat や -> Animal とすれば既存の言語機能で同じようなことが実現できます。しかし、 -> Cat では、内部実装を過剰に公開している -> Animal では、パフォーマンス上のロスが発生する という問題がありました。これを解決するために、 内部実装を隠蔽しながらパフォーマンスにも影響しない手

TL;DR, 優先度の異なる複数の制約を同時に定義することで、静的な定義だけで動的な振る舞いを実現できる 動的な要素の少ない構造のビューはより堅牢である はじめに 読みやすくメンテナンスしやすいソフトウェアを作るために重要なことの一つは構造をシンプルに保つことです。 iOSアプリのビューは壊れやすいソフトウェアの代表ですが、できるだけシンプルに作ることで変化に強い、堅牢で壊れにくいソフトウェアにできます。 動的な要素が少ないということは、ビューがシンプルであるということの指標の１つと言えます。 この記事では下記に示すような、スクロールに合わせて伸び縮みするヘッダーを、動的な要素を無くし、Auto Layoutの静的な制約のみで実現する方法を解説します。 動的な要素とは、実行時におけるビューおよび制約の追加・削除、Frameや制約を更新することと、機種やスクリーンサイズ、標準UIコンポーネン

Aug 12, 2018 少し前に、自分のStoryboardの使い方をツイートしたら割と反応があったので、改めてまとめてみようと思います。これまで何年かiOSアプリの開発をしてきて、Storyboardとの付き合い方は何度も変わりました。なので、今回紹介するものはあくまで2018年現在のもので、来年には変わっているかもしれません。 説明のイメージを掴みやすくするため、画面の例を用意しました。左が編集時のStoryboardで、右が実行時のiOSシミュレーターです。具体的なトピックが出た時に、この例を説明に使うことがあります。 記事の最後にこれが動作するサンプルコードも用意しましたので、興味があればどうぞ。 Storyboardを使う目的 以下の2つを重視して、Storyboardを選択しています。 動作確認に掛かる時間を短縮する 成果物の構造を把握しやすくする ただし、Storyboar