Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ReactNative のアプリを Swift に置き換えてます
Search
hayatan
February 24, 2021
Technology
0
530
ReactNative のアプリを Swift に置き換えてます
DMM meetup #26 〜とある事業が抱える課題と改善に向けた取り組み〜
https://dmm.connpass.com/event/203927/
hayatan
February 24, 2021
Tweet
Share
More Decks by hayatan
See All by hayatan
アプリ内課金 リジェクトとAppleとのやり取りのお話
hayatan
1
1.4k
Other Decks in Technology
See All in Technology
まだチケットを手動で書いてるの?!GitHub Actionsと生成AIでチケットの作成を自動化してみた話 / 20241207 Yoshinori Katayama
shift_evolve
1
800
最近のUplift Modeling手法にRでトライ
hskksk
0
130
テーブルが200以上あるSaaSでRSCとGraphQLを併用する理由
msickpaler
1
140
職能を超えたモブプログラミングが品質に与えた良い影響
tonionagauzzi
1
200
40歲的我會給20歲的自己,關於軟體開發的7個建議
line_developers_tw
PRO
0
2.6k
GitHub Actions의 다양한 기능 활용하기 - GitHub Universe '24 Recap
outsider
0
530
How is Cilium Tested?
yutarohayakawa
5
300
Raspberry Pi 秋の新製品をチェックしてみよう / 20231202-rpi-jam-tokyo
akkiesoft
0
480
EthernetベースのGPUクラスタ導入による学びと展望
lycorptech_jp
PRO
0
590
ファインディの4年にわたる技術的負債の返済 / Repaying 4 Years of Technical Debt at Findy
ma3tk
7
3.8k
WED Company Deck for Engineer
wed
2
3.7k
A/Aテストにおけるサンプルサイズ/japanr2024
nikkei_engineer_recruiting
1
620
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.2k
Rails Girls Zürich Keynote
gr2m
94
13k
Thoughts on Productivity
jonyablonski
67
4.3k
How STYLIGHT went responsive
nonsquared
95
5.2k
Embracing the Ebb and Flow
colly
84
4.5k
Visualization
eitanlees
145
15k
The Invisible Side of Design
smashingmag
298
50k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
We Have a Design System, Now What?
morganepeng
51
7.3k
Music & Morning Musume
bryan
46
6.2k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
Transcript
DMM MEETUP #26 React Native Swift ⼤⾨弘明 で書かれたアプリを で書き直しています
⾃⼰紹介 About me ⼤⾨弘明 合同会社DMM.COM エンターテインメント本部 オンラインサロン事業部 2014年: 新卒⼊社 いくつかのiOSアプリの保守や新規開発をするなど
2020年: オンラインサロン事業部にジョイン 主にiOSアプリを担当している
⽇ すこと A brief outline 僕にとって React Native はつらい React
Native to Swift は つらいが 理ではない ↑のような気持ちと の
僕にとってReactNativeはつらい
ライブ オーナーから 知 タイムライン Product 専⽤コミュニティアプリ 「DMM オンラインサロン専⽤コミュニティ」 を⽤いたサロンの 員専⽤のiOS
アプリ。
つらいこと React Native が負債に アップデートがしんどい
アップデートがしんどい そもそもしんどい Apple に従う ( OS, ATS, UIWebView...) これはどのみちつきまとう ReactNative
のアップデートがしんどい Xcode, RN, ライブラリ すべて動作するように 性のなくなるライブラリがある 式じゃないからRN ⾃体が いで、ライブラリはさらに そもそも僕は React Native がわからない Web フロントの技 は専⾨ アロー , スプレッド構 を ⽤した の羅列つらい
React Native が負債に iOS / Swift / JS / React
Native すべての い理 が必 当 はフロントエンドエンジニア主 で開発 iOS エンジニアがいなかった当時としてはベストな 択 iOS エンジニアを れてスピード/ 品 Up るが・・・ 度は JS, React Native が⾜かせに 得 野を⽣かせずつらい React Native を利⽤している 味はあまりない iOS のみ このまま使い けていくとデメリットの に苦しめられる
つらいこと React Native のアップデート もするからしんどい iOS エンジニアがJOIN したが スピードを し切れない
→Swift化して負債脱却しよう! React Native が負債に アップデートがしんどい
React Native → Swift は つらいが 理ではない React Native →
Swift
Swift の流れ Xcode, React Native を に Swift 基 を作る
的に Swift する
Swift の流れ Xcode, React Native を に Swift 基 を作る
的に Swift する
Xcode, React Native を に まずはビルドできるように Xcode と React Native
を にしてビルドが るまでエラーを り いていく → ひたすらトライアンドエラー npm のライブラリが していない場 npm の ライブラリがアップデートできない場 がある アップデートすると動作が保 できないやつ のXcode, React Native に していないやつ PR 状 でマージされてないやつ → patch-package を利⽤する
patch-package npm でインストールしたライブラリに パッチを当ててくれるツール https://github.com/ds300/patch-package ネイティブ にも利⽤可 Objectice-C(.m) ファイル や
podspec ファイル等も 正できる
patch-package 例: Podspec のReact だけ 正したい場 Xcode12 でビルドするために React を
React-Core に 更する必 があった。
Swift の流れ Xcode, React Native を に ビルドが るまでエラーを り
いていく npm のライブラリが していない場 patch-package を利⽤して 正 Swift 基 を作る 的に Swift する
Swift の流れ Xcode, React Native を に ビルドが るまでエラーを り
いていく npm のライブラリが していない場 patch-package を利⽤して 正 Swift 基 を作る 的に Swift する
内 奨アーキテクチャ VIPER ライクの 内 奨アーキテクチャを採⽤して 技 の流動 を る
React Native も1 つのモジュールとして利⽤ マルチモジュール で いずれ消えゆく React Native も1 つのモジュールとして、 ネイティブに ⾏した や ⾯からは しないように で る
Presenter⾃体は 状態を持たない Interacterは機能の呼び出しや ドメインの取得を⾏う
None
画⾯や機能のまとまりごとにFeatureモジュールを作る 画⾯や機能のまとまりごとにFeatureモジュールを作る ReactNative部分は1つのFeatureとしてモジュール化する ReactNative部分は1つのFeatureとしてモジュール化する
None
RN と Swift 間のやりとり Pub/Sub メッセージングモデル イベントを 知するSubject(Combine) 流れるのはイベントのオブジェクト(enum) Swift
へのメッセージ ⽤のメソッドはRN 側に 開 RN へのメッセージ ⽤のメソッド イベントオブジェクト(enum) を Dictionary に してRN に 知 処理 にI/F を やしていくのは けたい I/F を やすには ObjC のコーディング ( マクロ 義) も必 メソッド に やしていくのはしんどい
None
コードの⼀ receivedEvent(受信⽤) notifyToRN(送信⽤) Swift側からは、 を意識すればよい
Swift の流れ Xcode, React Native を に ビルドが るまでエラーを り
いていく npm のライブラリが していない場 patch-package を利⽤して 正 的に Swift する Swift 基 を作る 内の 奨アーキテクチャで技 の流動 マルチモジュールで を る Pub/Sub で RN <-> SWift を簡 に
Swift の流れ Xcode, React Native を に ビルドが るまでエラーを り
いていく npm のライブラリが していない場 patch-package を利⽤して 正 的に Swift する Swift 基 を作る 内の 奨アーキテクチャで技 の流動 マルチモジュールで を る Pub/Sub で RN <-> SWift を簡 に
的に Swift する 範囲の ない末 の ⾯からSwift 中で中 して の開発とかもあるかもしれない
Swift が に ⾏せずともアプリはリリースできる状 に Swift → RN → Swift → RN となる はしない 単 にコントロールが しい が になる
None
第2弾 第3弾 ... 第1弾
Swift の流れ Xcode, React Native を に ビルドが るまでエラーを り
いていく npm のライブラリが していない場 patch-package を利⽤して 正 Swift 基 を作る 内の 奨アーキテクチャで技 の流動 マルチモジュールで を る Pub/Sub で RN <-> SWift を簡 に 的に Swift する 範囲の ない末 の ⾯からSwift
まとめ 僕にとって React Native はつらい アップデートがしんどい ReactNative が負債 React Native
→ Swift はつらいが 理ではない patch-package を利⽤して未 のライブラリ 正 マルチモジュール で を に Pub/Sub メッセージングモデル で RN<-> Swift 間のを簡 に 範囲の ない末 の ⾯からSwift
おわり