3/3 スタートアップのSwift #tryswiftconf
try!Swiftのセッションまとめシリーズです。Mo Kudekiさんの「Startup Swift」についての記事になります。
資料
内容
リリースまで
- 1年間でビギナーとして体験した話をする
- 2016年初頭に製品を打ち出した
- その時Swiftを知らなかった
- MVPで出した
- 女性の友人同士の友情を育むアプリ（Early）
- 新しい街に引っ越した時に友達に会いづらいから
- 当時のコード
- バグがあちこちにあった
- 基本的な機能は揃っていた
- 初期の段階はいろいろ作らなければならない
- すぐにそれをやらなければならない
- メンバーも2人だった
- 自分たちでいろいろカバーしなきゃいけない
- いろいろなことを学んでいかなきゃいけない
- 協働創立者はエンジニア
- 自分の状況
- Twitterの仕事をしていた
- Objective-Cで書かれていた
- Swiftは初心者だった
- Twitterの仕事をしていた
- ParseとSwift
- 問題を片付けなければならなかった
- Parseとうまくいってなかった部分があったが誰も説明してくれない
- Swiftはシンプルで読みやすい
- CocoaPodsを使用
- 無事AppStoreで審査通過
- ここまでうまくいった
リリース直後
- インタビューを受けた
- 「女性の皆さんスワイプ一つで友人を見つけられるようになりました」
- 2週間で10万人のサブスクライブがついた
- 問題が出てきた
- こんなに多くの人が使うことを想定していなかった
- MVPがうまくいくということは今まで待ちすぎたということ
- 1分あたりのアクセス数を超えた
- お金払ってどうにかなるものではなかった
- 一人ずつアクセスするようにしてリクエスト数を絞り込んだ
- LAなどに限った
- AppStoreで一つ星たくさんになった
- インタビューによってアーリーアダプター以外の人も使うように
改善
- 「何か動かない」に対応してく
- 熱狂的なユーザとつながってやった
- フィードバックをもらった
- slackやTestFlightを活用
- クラッシュを再現することができないとfixできない
- Unwrapの見直し実施
- コードベースではextensionも役に立つ
- どこでも使えるように
- 新しい機能に対して改善していく必要がある
- 初めから全部を完璧にするなどではない
- 良いコードを書くというのはコスト効果が高いというわけではない
- 始めに書いたコードは排除
Parse停止
- バックエンドを新しく構築しなければ
- 全部一気に移行する
- 課題
- APIに特化したコードの部分がなかった
- リファクタリング
- 最初の6ヶ月ですぐれたところを列挙した
- これでも誰もチェックをしていないとバグが起こる
最後に
- Swift
- すみやかな学習カーブが特徴
- 初心者でも慣れ親しめる
- コードベースを改善しやすい
- 最も重要なところに時間を書けられる
- 人にとって価値のあるものを提供する
- はじめにサッと作ってみる、Swiftで構築してみるのをぜひ試してみては
Q&A
- 今後スタートアップとして新しいアプリを作る場合でもparseなどを積極的に使った方がいいのか
- parseから移行した時にコードベースを分けてインフラに書き込むようにしたとのことだがそのまま移行するという選択肢を選ばなかった理由は
その他このトークに関する情報源
- [速報レポート] try! Swift TOKYO 2017 2日目 午前Ⅱ #tryswiftconf ｜ Developers.IO
- スタートアップのSwift | try! Swift Tokyo 2017 #tryswiftconf Day2-6 聞き起こし - niwatakoのはてなブログ
