iOS 8 Debugging Case Study | Hacker News Reader

iOS 8 Debugging Case Study

objc.io

79 pointshoggle25 comments

This is a really great read, especially for new iOS developers who haven't picked up a ton of debugging tricks from experience alone.

In particular the section "Calling Conventions 101" contains a lot of very useful information that isn't documented very well in any of the iOS resources provided by Apple (AFAIK). Commit it all to memory, you'll be glad you did :)

The calling conventions are described here https://developer.apple.com/library/ios/technotes/tn2239/ with links to more in depth descriptions and other useful informations.

This article has some more good tips on extracting information from those registers. http://www.sealiesoftware.com/blog/archive/2008/09/22/objc_e...

Apple uses the standard calling conventions for the CPU architectures they use, so there's no real need nor expectation for Apple to document those aspects beyond saying "we use the standard conventions," which they do say if you go digging. In some instances they also replicate the documentation for the conventions.

Well, for new developers they might not put together "we use this calling convention" with "and that means you can find things like self, _cmd, or the exception that was thrown in these registers ... which can ease debugging your app". That's useful information I wish they'd put up in their docs, is all.

It's not obvious that you can meaningfully talk about to "the standard conventions" on i386, x86_64, or armv7, as there are at least two widely-used conventions for each. arm64 comes the closest to having a single "standard", but Apple uses a (documented) tweaked version.

> It's not obvious that you can meaningfully talk about to "the standard conventions" on i386, x86_64, or armv7, as there are at least two widely-used conventions for each.

x86_64 has the System V AMD64 ABI calling conventions which are as standard as can be and used by almost everybody. Microsoft being their usual assholes does not mean their ABI is anything other than their ABI.

    Microsoft being their usual assholes does not mean their ABI is anything other than their ABI

Not helpful.

Plan 9, and therefore The Go Programming language use a different one, which is the same across all architectures supported by Plan9's assembler. (It's one reason why cgo call's are not cheap)

Does anyone else feel like maybe the entire iOS development experience is batshit insane?

I wouldn't say the entire experience is insane, but a lot of things feel unnecessarily difficult (hello crash symbolication, auto-layout debugging, etc...) compared to their web development counterparts.

On the other hand, you do get greater performance and stability (but not perfect stability, after all it wouldn't be an iOS release if Apple didn't break something and completely ignore radars).

Not really, I work on iOS code much more complex and rarely have to stoop to so many tricks. Due to having to support iOS 6 I still have to use XCode 5 so some of this isn't even available to me. After a while you figure out the problems just from the symptoms. My current project was written by Elbonians who were paid a pittance so there is lots of fun debugging.

That said figuring out bugs in iOS is a major league PITA. I have one now in NSURLSession which is batshit insane.

There's a lot of extremely frustrating and stupid aspects to it... but none of those are in any way related to anything discussed in the article, so I find your comment a bit odd. What makes iOS development so frustrating to me is the constant struggle with code signing, device provisioning, Xcode crashes, random failures to install or run programs, and all the craziness around App Store review.

I agree. I just started to learn iOS development at my current job (around 4 months), and configuring with code signing & XCode configuration is a pain in the ass.

I struggled with those, but after a few years doing iOS dev, it isn't so bad. It all eventually sticks.

And autolayout is freakin awesome imo, though I hear a lot of people groak about it.

Still hasn't become "not so bad" for me after many years.

Autolayout is horrible in the sense that when something isn't working, it's really hard to figure out what went wrong. My personal favourite is when you forget to set translatesAutoresizingMaskIntoConstraints to NO on a container view. A whole bunch of implicit constraints pop into existence that conflict with your actual programmed constraints, and the error message that tells you that you have constraint conflicts really doesn't help you in figuring out where the constraints are coming from. Eventually you figure this out, and you don't get caught out by it any more, but in the learning phase, it's quite painful.

Something else I really dislike when it comes to constraints - they don't play well with animations, at least in my experience. I recently created a view that had a variable number of square buttons in it that were laid out in a grid two rows high. Making a nice animation when you add a new button, fading in the new button, and sliding the others out of the way was nigh on impossible (ie 'not possible without writing more code than if I had just done the layout manually). And yet, this seems to be the perfect use case for auto layouts...

It's really, really nice for making static layouts in IB, but as soon as you do anything dynamic — programmatic views, animations, etc. — the whole thing becomes a burden.

I often wish we had something akin to autolayout for CSS.

This is exactly why I don't use it. I do iOS development since the first SDK public release, I have a love/hate relationship with Interface Builder. I used to use it a lot, but now I use it only in small projects. Storyboard is awesome for small apps.

But for my big projects I do 100% of the UI in the code, if the UI use a lot of custom control, it just not worth it to use IB, the end result is that what you see is not at all what you get. BUT it improved a lot with Xcode 6, because now it can render custom views live in Interface Builder.

Auto layout on the other side.... it's just broken.... Every time I try to use it I got what you mentioned in your first paragraph. And I do a lot of animations in my apps, and playing with 10 constrains instead of a simple frame is just .... too much of a burden.

Again, for big custom apps I don't use it, but I love those functionalities for small & simple apps.

Not compared to my experience with other mobile platforms.

have you ever developed something on Android? Oh man, that is insane!

Debugging is insane?

No. I have never had to use the assembly/decompiling tips described in this article, and 99.9% of programmers will never have to do it, either.

Even with a problem like this, you can fix it or get around it with a bit of trial and error. As with any other black box technology.

(Still useful to know, though.)

Seems so, but then I am a JS developer, and you know what they say about glass houses. And really, everything we do is completely nuts if you think about it.

No, sounds fairly typical native development experience, if not one of the best ones.

Plus the term "batshit insane" has been overused. What you'd use to call some really bizarro thing when you do see one?

Yes. It all begins with having to provision your own device, and slowly slides into "people are strange when you're a stranger" territory from there on. The worst part is pointing out each individual folly, only to have it met with skepticism, criticism and fanaticism by Apple fanbois. Luckily Stack Overflow has unveiled thousands, if not tens of thousands of pitfalls in iOS development so I don't think anyone can argue that it represents any kind of elegance anymore, only that it is better than some other environments (which often isn't saying much). Yet this is how I earn my living, so in the end, I guess I accept it despite its (numerous) flaws.

Reply on news.ycombinator.com