With Apple now using some kind of static analysis tool to analyse applications submitted for App Store review, it’s had me thinking: why not let us test with it prior to submission - or have iTunes Connect immediately analyse upon uploading a binary? With it widely commented that the first 8 days of any review are to encourage developer self-moderation and bug discovery, the notion that developers have to wait 8 days for an automated process to run is - quite frankly - ridiculous.
As has been noted elsewhere, developers could indeed work around a desktop version that provides you with a hint of ‘You might want to fix these things’ when building a Distribution build, in an attempt to circumvent the analyser. However, if a developer were to receive an automated confirmation or warning within 24 hours of the initial application submission, it’d at least be a start.
Sidenote: Yes, developers can avoid the use of certain private frameworks (and undocumented methods in public frameworks), however we’re only human and honest mistakes can happen. This suggestion isn’t so much a way to work around deceptive attempts to contravene Apple’s (admittedly wolly, and continually fluid) App Store policies as it is a way to ensure that people who do make honest mistakes don’t wait 8 days to hear about it.
My decision to stop iPhone development has had everything to do with Apple’s policies.
On Tuesday evening, I gave a short talk at the Brighton iPhone Developer group. As I’m not entirely ready to take the veil off my forthcoming iPhone app just yet, I decided to run through a few handy things I’ve come across in development. Seasoned OS X developers will probably be more than familiar with some of these, but figured I’d post a list of everything mentioned in the talk for good measure.
As for the application itself (which I did give a brief demo of): more soon. Hopefully.
Update: Seasoned developers might also want to take a look at AQXMLParser. It’s awesome, and I definitely wasn’t bullied into plugging it here….
If you’re not embarrassed by your first release, then you launched too late.
Justin Williams’ piece Die You Damn, Dirty Tab Bar has had me thinking for the past week - and I’ll admit that I’ve been meaning to post something meaningful about it ever since - particularly this quote:
Rather than taking the easy way and slapping a tab bar at the bottom of your UI, put the extra effort into the design process to see if it is possible to do the application using a single navigation stack.
Whilst the Tab Bar isn’t designed to be used in every situation, I’d say it’s far from a cop-out if what you’re looking for is quick navigation around the app. Take, for example, an app I’m working on at the moment - please excuse the vagueness :). There’s uses where, if the user doesn’t see something of their liking in one tab, they might want to search for something instead. In your usual drill-down application, you’ll have switched to view A, and need to somehow get to the search view (B). That requires 1 tap to return to your homescreen and another tap to head to the Search view. With the Tab bar, there’s just one: to the view in question. When speed is the order of the day, I can’t help but find the Tab Bar to be my navigation of choice - particularly when walking along and using the iPhone with just one hand (and predominantly using my thumb).
Of course, that’s not to say that speed in a drill-down isn’t possible. There’s one prime example of this: Buzz Andersen’s very excellent Twitter client Birdfeed (which Justin also uses as an example). The number one thing in Birdfeed that makes it a joy to use is the simple ‘Return to Homescreen’ button that makes it easy to get to the top of the navigation stack. It’s also something that the likes of Tweetie (and most other Tab Bar based applications) could learn from, ironically.
Be sure to see Justin’s followup where he takes a Tab Bar application, and suggests how it might be reworked.
If you’re doing iPhone development, this is almost certainly not new to you. However if you’re ever doing a little bit of iPhone development (as I’m currently doing) and need to test your app’s handling of low-bandwidth connections, Speedlimit lets you artificially constrain your net connection (or specific hosts) to WiFi, 3G, EDGE or GPRS speeds.
I’m heading to Atlanta next week for the Big Nerd Ranch’s Beginning Cocoa Bootcamp whilst my comrades head to WWDC. The 7-day course (which starts on the 12th June) is one of the last that Aaron Hillegass is teaching and (unusually) there’s still three places left. It’s kicking off on the Friday of WWDC (and certainly not cheap) but if you’re wanting to learn Cocoa this is the place to be.
I seriously can’t wait.
Fraser Speirs talks about his recent acquisition of Changes.app (an OS X File Comparison and Diff-ing application).
I’ve been following this for some time on iTunes U. There’s some great content.
© Nik Fletcher 2007-2011 ~ Contact
