iOSDC Japan 2020 Day1 13:20~ Track B プロポーザル:https://fortee.jp/iosdc-japan-2020/proposal/3fb66bbc-5a43-44d0-aa60-89abb12939e1 参考実装:https://github.com…
iOSDC Japan 2020 Day1 13:20~ Track B プロポーザル:https://fortee.jp/iosdc-japan-2020/proposal/3fb66bbc-5a43-44d0-aa60-89abb12939e1 参考実装:https://github.com…
Any great software developer must inevitably become a great software debugger. Debugging consists largely of setting breakpoints, then landing on them to examine the state of an app at arbitrary points during its execution. There are roughly two kinds of breakpoints: those you set on your own code, and those you set on other people’s code. Setting a breakpoint on your own code is simple. Just find
total time: 3.4 seconds (100.0%) total images loaded: 337 (264 from dyld shared cache) total segments mapped: 235, into 16189 pages with 3084 pages pre-fetched total images loading time: 2.8 seconds (83.3%) total dtrace DOF registration time: 0.11 milliseconds (0.0%) total rebase fixups: 246,514 total rebase fixups time: 80.71 milliseconds (2.3%) total binding fixups: 311,397 total binding fixups
(lldb) po [self _ivarDescription] <DetailViewController: 0x7fc94b637db0>: in DetailViewController: in UIViewController: _view (UIView*): <UIView: 0x7fc94b63c360> _tabBarItem (UITabBarItem*): nil _navigationItem (UINavigationItem*): <UINavigationItem: 0x7fc94b63ae20> _toolbarItems (NSArray*): nil _title (NSString*): nil _nibName (NSString*): @"jAO-Jw-mTY-view-IBP-J8-Ec0"<__NSCFString: 0x7fc94b6380e
Everything You Need for Reverse Engineering Hopper combines powerful analysis capabilities with an intuitive Mac-native interface, giving you professional-grade tools at an affordable price. Hopper Disassembler for Mac requires macOS 12.4 or higher. Native UI Built with a blazingly fast, beautifully polished Cocoa interface that prioritizes keyboard shortcuts and native macOS integration for a smo
http://www.objc.io/issue-19/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 objc.ioはベルリンのメンバを中心に、月替りでiOS関連技術の特定のテーマに絞って発信しているブログ。もう既に知名度はかなり高いかと思いますが、毎月ものすごく力の入った特集ゆえに、その分ボリュームも相当で、読むのも大変というか、時間がないから読めてない人もいるかと。今月は#19としてデバッグの話題です。 Peter Steinbergerの「デバッグ : ケーススタディ」では、UIKit上のバグをLLDBで対処した話を紹介。 「デバッガーでのダンス - LLDBのワルツ」において、Ari GrantはLLDBの使い方を詳説してくれています。 「DTrace」はiOSシミュレータでしかまだ利用で
バグってんだけど…これちょっとおかしい…デザインくずれてんだけど… といわれてスクショだけ送られてきたことが一度はあるかと思います。 (まぁどういう状況なのか見た目から推測できるので無いよりもマシだけども...) さて、スクショだけを送られてきてバグってるといわれた時に何が困るでしょうか。 それは情報が足りずにデバッグを始める前に情報集めをしないといけないことです。 当然ユーザーのための画面にエンジニアが必要な情報が出ていることはまずないでしょう。 個人的にはこの情報を集めるのがクソめんどくさい!!!!!1 送ってきたユーザーはだれ? デザインが崩れているデータはどれ? 自社で API も開発してる場合は原因はサーバーサイド?それともクライアントサイド? スクショを撮った時に表示されてる UIViewControll
原因がよくわからないのですが、iOSアプリをデバッグ中にNSExceptionが発生してアプリがクラッシュしてしまった時、その詳細がXcodeのコンソール上に表示されなくなってしまいました。普通はデフォルトのexception handlerがうまい具合にやってくれるのですが、何らかの理由でそれがうまくいかない場合があるようです。自分でスレッド立ててるとかでしょうか・・・ 上図のように、例外が発生している箇所にブレークポイントをおいてどこで発生したのかを知ることはできるのですが、実際には発生箇所がわかっても発生原因がさっぱりわからないというケースもあります。例えばiOSのシステムが例外を発生させたときや、コードが公開されていないライブラリが例外を発生させたときなどです。 さて、このようなときは発生しているNSExceptionのdescriptionを直接読めれば便利そうです。というわけで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く