Just in time for tomorrow’s press conference, the update is out to solely address the “erroneous” signal display issue. There’s a 2.28GB SDK update available for developers too, making that the second SDK release in two days. My ISP is going to hate me.
This looks super-handy: a drop-in web service sharing for iOS apps (think posting items to Twitter, Facebook, Delicious etc). It’s open source on GitHub, and entirely customisable. Whilst it’s intended to be used in its entirety, if you’re wanting to (say) implement Twitter sharing in your own iPhone app with xAuth login you can still use ShareKit to implement the service on its own.
Tim Van Damme posts an excellent followup to his first article on designing for that 326ppi screen. If you’re a designer or developer, with access to the iPhone Developer Portal, this link is the one you’ll want to check before June 24th.
Stanford University have just put their iPhone Application Development Course (Winter 2010 edition) on iTunes U. It’s free!
Last summer, I flew to the States for Big Nerd Ranch’s Cocoa Bootcamp. It’s not cheap, but it’s taught by Aaron Hillegass: the guy who wrote the book on Cocoa - and I learnt an incredible amount. Talking of books, I read a fair amount of those too - and played with a lot of sample code, hacking away at pet projects to see how things work.
If you’ve got a question you want to ask, fire away. All previous questions are tagged Ask for your viewing pleasure.
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.
© Nik Fletcher 2010 ~ Contact
