Woogaでエンジニアリング部門のトップを務めるJesper Richter-Reichhelm氏は，GOTO Amsterdam 2014で，継続的デリバリの考え方でモバイルゲーム開発を実施した際に，チームが直面した課題について講演を行った。その中で特に強調したのが，モバイルソフトウェアのデリバリプロセスに関して，自分たちがコントロールを持たないためにビジネスが崩壊直前に至ったという，その経緯についてだ。
氏が紹介したのは昨年末，App Storeで公開したモバイルゲームの新リリースの際のことだ。App Storeでの審査に4日を要したこのリリースには，15%のユーザに影響を与える重大なバグが潜んでいた。バグを修正して，新たなリリースをApp Storeに提出するまで数時間しか掛からなかったのだが，米国で感謝祭の休日期間に重なったため，実際に新しいバージョン５がユーザに届いたのは5日後だった。その間の数千件という悪評価のレビュー，被害を被った20万近いユーザによって，ゲームが，さらには会社自体が危機に陥った，と氏は語った。
Webでは一般的な手法になりつつあるカナリアデプロイメント(新リリースを管理的にロールアウトする方法)，あるいは機能スイッチ(Feature Toggle)といった継続的デリバリの手法は，App Storeのリリースプロセスではサポートされていない。この制限を回避するためにWoogaでは，オンラインでのゲームの設定サポートに投資すると同時に，ユーザをセグメント化して特定機能のカナリアデプロイを可能にする“人為的”なデバイス要件("カメラを備えている"というような)導入などのトリックを繰り返していた。それでもなお，アプリケーションのインストールはユーザ次第であり，ユーザベースの最大10%が18ヶ月以上にわたって旧バージョンを使い続けている。オンラインでプレイするように強制アップデートを実行しても，オフラインでアプリを使用するユーザがいるのだ。
さらにWoogaでは，App Storeへの提出用のビルドを，専用マシンを使って手作業でリリースする方法を廃止した (ただし氏は，クラッシュ解析に備えてdSYMファイルをバージョン管理するように推奨している)。この方法では単一障害点が構成されるため，新しいビルドをApp Storeに送信する必要のある場合には，修復時間を増大させることになるからだ。また，内部のユーザが新しいバージョンのゲームをテストできるように，リリースプロセスを模倣した社内App Storeもセットアップした (Facebookと同じような方法だ)。
デリバリ機構とMTTR(Mean-Time-To-Repair/平均修復時間)の他，Woogaにおけるモバイル開発の大きな課題として氏が挙げたのは，ネットワークやデバイス面でのコントロールが欠如していることだ。
特にモバイルネットワークの遅延の変動やオフライン利用は，データの損失につながるため，結果的にデータの整合性を維持することや，ユーザが直面している問題のデバッグを難しくする。Woogaではこの問題を最小化するため，モバイルクライアントとの非同期通信の導入やすべてのメッセージを(数日前のものでも)等しく処理する，あるいは更新の競合解決にETagを使用するなどの方法を試みている。