基本的には外部モジュールではなく、自分のソースコードを疑うべきなのだけど。
—
この記事の問題は、現在は改善されています。
2013年08月16日に公開された、1.5.2のSDKにて、以下の問題は修正されたようです。
—
しかしかし、
更新後に落ちるようになって、
修正がほぼその部分だけで、
届いたクラッシュログが位置を示している。
なので、現在配布されている、
1.4.0_a のアイモバイルメディエーションアダプタは、危険と判断しました。
Wifiではほぼ発生しないのだけど、3G回線で２度のクラッシュを自分でも確認(2013/7/5 夕方の時点)
アダプタを利用せず、カスタムイベントで実装すると、問題ないという情報があります。 シンプル・ダイエットな@Awaresoft さんより。
しかしかしかし、
一度モジュールを配布してしまうと、そのあとでカスタムイベント対応したとしても、アプリ更新をしないユーザーさんは、広告を再開するとまたクラッシュする可能性が出てきます。
と、お風呂で考えてたら、そういえばアダプタとカスタムイベントは別物でした。アダプタを止めつつ、新規のカスタムイベント開始でどうにかなりますね。
不具合報告として、アイモバイルさんへ伝えましたが、どうにかモジュール変更なしで（サーバ側で）修正できないかなーとか思うのだけど。
モジュールがずっと公開されているってことは、、、うちの問題なのかもしれないし、
うーん。。まいった。
コメント
この件、私もかなり時間を割いて調査をしております。誤解のないように補足を書かせていただきます。
アイモバイルさんにはお世話になっているのであまり不名誉な情報を拡散するのははばかられるのですが、一方で1ヶ月ほど前からクラッシュログを送って調査を依頼しているのに回答をいただけておらず、不具合がある可能性が高いアダプタが未だ公式ページで公開されている現状に開発者として危機感を感じております。。。
私もCocoamixさん同様に自分のソースコードではなくアダプタを疑わざるを得ないと判断したのは、下のようなクラッシュログがiTunes Connectに多数届いており、また手元のデバッグ環境でもクラッシュが再現できているためです。
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x3ad6e5b0 objc_msgSend + 16
1 SimpleWeightPhoto 0x001fa7fc -[IMobileAdapter stopBeingDelegate] (GADMAdapterIMobile.m:112)
2 SimpleWeightPhoto 0x0015d328 -[GADMAdNetworkConnectorImpl askAdapterToStopBeingDelegate] (GADMAdNetworkConnectorImpl.m:98)
3 SimpleWeightPhoto 0x001598c4 -[GADMAdManager adNetworkTimeoutHandler:] (GADMAdManager.m:377)
4 Foundation 0x339e5f4e __NSFireTimer + 58
5 CoreFoundation 0x330a35dc __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 12
6 CoreFoundation 0x330a328c __CFRunLoopDoTimer + 268
7 CoreFoundation 0x330a1efc __CFRunLoopRun + 1228
8 CoreFoundation 0x33014eb8 CFRunLoopRunSpecific + 352
9 CoreFoundation 0x33014d44 CFRunLoopRunInMode + 100
10 GraphicsServices 0x36bd82e6 GSEventRunModal + 70
11 UIKit 0x34f2a2fc UIApplicationMain + 1116
12 SimpleWeightPhoto 0x000bf18a main (main.m:15)
13 SimpleWeightPhoto 0x000bf14c start + 36
ログから、広告がタイムアウトになったときのアダプタ内の処理（[IMobileAdapter stopBeingDelegate] ）に問題があるのではないかと考えて、1ヶ月ほど前よりログを送って調査を依頼していますが、未だ回答がいただけておりません。
また、記事に書いていただいたように、アダプタを使わずカスタムイベントで実装してからは、上記のクラッシュは発生しなくなりました。
もちろん、アプリ側の実装の仕方で回避できないこともない可能性は完全に否定することは出来ないわけですが。。。-_-;)
同じ轍を踏む人が続出してしまう前に、アイモバイルさんから公式な見解が発表されることを祈るばかりです。。。
＞くらっちーさん
コメントどもです！
具体的な原因よりは、偶然であれ２人が同じ状況になっている点ですね。
クラッシュは致命的な不具合なので、極力起きてほしくないです。
そのクラッシュを避けるための方法があるなら、それは有益な情報なので、広まるほうがいい！
不具合にデバッグで追えない部分が絡んでくると、追いたくはないし、追うべきでもないです。
名誉云々ではなく、単なる何かの不具合なので、こういった情報がなにかしらの改善に協力できていればいいですよね。
そして『更新したらアプリが落ちるようになった！』という星１レビューが、いくつか減るはずです。
そうですね。
非常に残念なのは、クラッシュが再現できない場合やログがない場合は調査が難航するということは多々あると思うのですが、再現方法（リクエストのタイムアウト）が分かっていて、クラッシュログまであるのに、「調査中」という回答しかいただけないところです。（公式に配布するライブラリを書けるレベルのエンジニアがこのクラッシュログを見てさらに再現方法もわかっているのに問題を特定できないというのは非常に考えにくいですよね。）
アプリ側の問題という可能性は100%否定することは出来ないわけですが、しかしここまで明らかになっているので、早期に何らかの公式な発表をしていただいて、これ以上同じ轍を踏んで★１レビューをつけられる開発者が増えないことを祈るばかりです。。。
こちらを見られた方は、現状、アダプタの組み込みではなく、カスタムイベントで対応するのが得策だと思われます！