Under the Bridge

Source: iPad Dashboard

Here’s your daily dose of niftiness; this clever spark created an iPad version of Dashboard.

Inspired by Apple’s Dashboard application for Mac, Dashboard for iPad has been completely rewritten for iPad. It brings the ability of running multiple mini-applications, widgets, to all iPad users. With access to any of the existing Dashboard widgets for Mac available to download right within this application, you can quickly add several fun and functional widgets to your Dashboard.

Yep, that’s pretty cool alright:

Screen shot 2010-04-14 at 11.13.33 PM.png

Sounds like something you’d find handy, yeah? Well, not in the opinion of Apple. Boo, hiss.

Alas, Cupertino has now rejected the app for “contradicting the iPad’s user experience”, whatever that means…

Cha. Yes, sometimes they are genuinely annoying, aren’t they. But hey, at least you can run it yourself if you like, since the author has been kind enough to opensource it on GitHub!

h/t: TechCrunch!

Continue Reading →

The Great Section 3.3.1 Debate

So no doubt you’ve observed the great spectacle of frenzy over the infamous Section 3.3.1 (there’s a T-shirt in there somewhere, I know it) of the latest developer agreement:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

… with reactions from the profane to the pedantic to the metaphysical to the insightful to the whoa, dude.

Rather than weigh in one way or the other on the emo angst surrounding the apparently imminent demise of not only Flash Packager but also Corona and iPhoneWax (Lua), MonoTouch (C#) and theoretically even scriptable engines like Unity, we’d like to draw your attention to the pretty much completely overlooked point of exactly what is explicitly allowed. Specifically, JavaScript.

First observation is that leaving that as an option means you can completely throw out every “it’s all about the money” or “Apple wants to stop cross-platform development” argument immediately. As we’ve mentioned before, HTML5 apps are completely cross-platform, you can avoid the App Store with them, and Apple has gone to a fair bit of trouble to make the offline HTML5 app experience pretty darn close to a native code application experience. So several whole classes of anti-Apple rant are rendered moot right there.

Explicitly blessing JavaScript in this section, though, that seems to imply that frameworks using HTML5 to deploy App Store versions of cross-platform apps is not only tolerated but specifically consecrated. (Given the … fervor … surrounding the issue, religious imagery seems appropriate.) At the very least, it certainly cements the resolve we’ve been mentioning here and there to get familiar with this alternative sooner rather than later. And despite what some commentators are saying, it appears that proudly cross-platform App Store-targeting JavaScript-based frameworks like Titanium and PhoneGap and NimbleKit and Rhomobile [EDIT: Oops, Rhomobile is actually Ruby, they might be out of luck] and other miscellaneous bits are not just allowed, they are actively encouraged.

Indeed, we have word that Apple sees it that way too, at least for PhoneGap:

[ Update:: April 13, 2010 ]

I have received word from Apple that the above is STILL true! If you were concerned by the recent changes to Apple’s iPhone developer agreement, this has ZERO impact on PhoneGap!

Apps built with PhoneGap will continue to be reviewed based on their own merits and NOT dismissed/rejected because they use PhoneGap.

So enough with the crazy speculative rumour mill. Let’s get back to making apps with HTML+CSS+JavaScript.

PhoneGap ftw!

So there you go. You want to develop cross-platform apps, you have one already sanctioned environment and others that look like they’ll probably be deemed equally acceptable to do that. You want to focus on the iPhone, far as I’m concerned Apple is actually doing you a favour by keeping all the Flash gits out of your way. Either way, there is no problem here.

And one last thought for those that are still upset:

If Flash is such a great platform -it’s actually not bad but not that good either- go ahead and develop these killer apps on Android or WinMo7 whenever that comes out. With killer apps being available on competing platforms making a huge difference Apple will simply change the clause and allow you in. They’re not stupid.

Indeed. If you’re absolutely, totally, convinced that this is a bad move on Apple’s part … well you go right ahead and prove that!

Continue Reading →

SQLite Intro

So you took away from the post on when to not use Core Data that it would be good to get a little more understanding of SQLite, but are finding a dearth of iPhone-focused documentation? Well, has Ray Wenderlich got just the two-part series for you!

In this series, we’re going to show how to make an app that displays a list of failed US banks from a SQLite database.

In this first part of the series, we will cover what SQLite is and why we’d want to use it, how to use the sqlite3 command-line utility, and how to import data programatically via Python.

In the second part of the series, we will cover how to make an iPhone app that reads data from the SQLite database we created, and display data in a table view and a drill down detail view…

SQLite 101 for iPhone Developers: Creating and Scripting

SQLite 101 for iPhone Developers: Making Our App

That’s some seriously good tutorial there. And check out the back history while you’re there, lots and lots of good stuff that we haven’t specifically linked to, particularly what’s probably the best cocos2d introduction around.

Continue Reading →

Shiny buttons redux

As you may recall from before, we’re all about the shiny glossy buttons, and the latest tool in the endless quest for shininess is a particularly nifty one: based on RRGCausticShader an OS X implementation and ported to the iPhone, complete with an app to determine precisely the flavor of shininess to display!


Yes, that there’s some serious shiny control indeed. Source is on github, enjoy!

Continue Reading →


Here’s a neat trick: parsing a variable argument list into an NSInvocation call in order to call an arbitrarily argumented method on the main UI thread.

… Too bad that they are untyped? 
No despair, we know the target object for our invocation, and we know what method to call. So we have what we need to fetch the NSMethodSignature object for the call, that contains all the type information we need to safely process the va_list.

Our target machine is a Mac running 32- or 64-bit Intel CPU, or an iPhone OS device with a 32 bit ARM CPU. Turns out that on both platforms va_list is simply a void* pointer, to the stack frame. Even better va_start() will always flush any argument passed into the register on the stack frame. So we can skip most of the boring argument handling, by treating the arguments like a byte buffer, only advancing and aligning the buffer according to the information in the NSMethodSignature object…

Not too sure that we’d actually recommend this as being a particularly good practice as compared to the conventional process of packing up your arguments in an NSDictionary, but it’s rather interesting code to look through and see just how the variable arguments are reconciled with the NSMethodSignature. Just in case you ever have a good reason to know how!

h/t: LinkedIn’s CocoaTouch!

Continue Reading →

Cypress Expansion Board Kit

Ooooh, this is really really nifty: Ever had any desire to do an iPhone hardware accessory? Well, looks like doing so just got a lot easier:


The easy-to-use PSoC-based development platform enables highly-integrated modular design of functions such as capacitive touch-sensing, LCD segment drive and much more for traditional iPhone and iPod accessories such as audio docks and speakers, chargers and automotive products. The platform also opens up a new realm of accessories that can leverage the 480 x 320 touchscreen display and many other features of the iPhone and iPod touch for a myriad of markets and applications, including health and wellness, point-of-sale, RFID, and diagnostics and instrumentation tools. Details on the new kit and a video demonstration are available at www.cypress.com/go/cy8ckit-023

Almost enough to make us wish we knew anything about hardware design!

h/t: MacSurfer!

Continue Reading →

iPad 3.2 SDK Roundup

So since it looks like we’ll be talking about all the new stuff in the 4.0 SDK very shortly, let’s take a minute here to round up some of the more worthwhile posts on what’s new and exciting in the newly not NDA’d 3.2 SDK for the iPad:

Jumping from iPhone to iPad Development, A Beginners Guide

The Good and the Bad: iPad from a Developer’s Point of View

What’s new in iPhone SDK 3.2

Noticed any others worth a gander, Dear Readers?

Continue Reading →

Tutorial: HTML5 iPhone App

Here’s another one in our dribble of  occasional mentions of the offline HTML5 alternative to building iPhone applications, just in case we ever have a problem with App Store restrictions or the need for a cross-mobile-platform deliverable enough to actually get into it:

How to Make an HTML5 iPhone App

… I’ll show you how to create an offline HTML5 iPhone application. More specifically, I’ll walk you through the process of building a Tetris game.

What am I talking about when I say “offline”? Well, it means that we have a custom icon, a custom startup screen, a native look-and-feel, and you can use the app even when the phone isn’t connected to the Internet.

The app should be as functional as it can when it is offline, just like normal native mobile apps.

This is a tutorial specifically for iPhones but most of these techniques apply to all phones that have HTML5-capable browsers…

Thorough walkthrough, easy to follow, covers offline data storage even. Good stuff, good stuff!

h/t: MobileOrchard!

Continue Reading →

Tip: Build and Archive

Just in case you missed this in the release notes for the iPhone SDK 3.2 which is final now so go download it, Xcode 3.2.2 has a handy-dandy new ‘Build and Archive’ command which will place your app and .dSYM into ~/Library/Mobile Device/Archived Applications, and list it in a new ‘Archived Applications’ entry under ‘iPhone Development’ in the Organizer window; from where you can run Apple’s initial validation checks if its metadata is on iTunes Connect, submit it directly, or hit the shiny new ‘Share Application…’ button, which will let you either save somewhere or email directly an .ipa file signed with your certificate of choice.

So, with any luck, it’s goodbye forever to those pesky ad hoc build distribution problems, and without needing to resort to workarounds like dsym-archiver. W00t!

Continue Reading →


OK, today we’ve got something for you that every single iPhone application developer should implement immediately. It certainly would have saved us being reduced to gibberingly apoplectic frustration last year. At least, you should implement it immediately if you’re not absolutely 100% certain that your app will never crash either because of your own code or because of any change in system libraries’ behaviour. Feel free to stop reading now if that’s the case.

Ah, you’re still here. Yes indeed, even if you yourself do happen to be absolutely perfect, those people who left because they trust Apple are pretty silly, aren’t they now? So let us continue.

The immediate problem we’d been faced with was bug reports like this one:

I observed the app crash during [REDACTED]. This occurred when a button was pressed…  [REDACTED] I believe. But I have tried this additional times and have not observed a crash, so it is not easily repeatable.

Those are great, aren’t they? And of course, the idea of a user being able to follow instructions like “please send me the crash report, which you can find after you next sync at this path…”, well that’s just crazy talk. So we decided that for the sake of our blood pressure, we needed to put in some way to get those crash reports directly. And it seems that state of the art in free code to help you out with that is still the long-ago–mentioned PLCrashReporter … but there’s a new twist to it. An awesome twist. On awesome toast. With a side dish of awesome. And that twist would be the CrashReporterDemo project.

Really, it’s quite sadly misnamed indeed, because it’s not just a reporter demo, it’s a complete crash management and automatic feedback system. “And automatic feedback?” you say? Why, yes, indeed, “and automatic feedback”, we said. Like this. Your app crashes, next time it starts the user gets a screen like this (pardon the greenly redacted bits, but this project is still SOOPER SEEKRIT):


No particularly big deal so far, if still waaaaaaay better than most apps manage. But this, ah this is the awesome part, the user taps ‘Yes’ and nigh on immediately this shows up:


Woah. Have you ever seen any application do that before? We have never seen any application do that before. That’s just so insanely awesome that “awesome” blushes and hides itself as not being up to the task of adequately conveying its awesomeness. We do so wish we’d had this last summer as the angry emails poured in and the angry one-star reviews piled up and we begged the grinning gargoyles athwart the Apple approval process to p-p-p-please let us publish a four line fix as they sat back on their evil haunches and cackled hysterically at our discombobulation. Alright, perchance we exaggerate somewhat; it may be that their cackling was not actually hysterical. But it felt that way at the time. Not that we’re bitter or anything, mind you. It was an educational experience that poking around the undocumented corners of the SDK is actually not as clever an idea as it may appear at the time. But we digress.

How this project brings the magic is that it includes online PHP scripts to handle the submission — and local support to symbolicate the crash reports on your own machine and send them back up to the server, how awesome is that indeed — sort it by version, and identify them as being a particular “pattern”. And you can set a fix and a fixed version online to that pattern. Like, for the above, this:


and then on the versions screen — which will fill in the future version you note for a fix automatically — set the type of resolution (fixed, submitted to Apple, now available for upgrade, …) and tell it to notify future submitters;


… and then they will get an appropriate alert as shown above.

So yeah, I trust that now you follow where we were coming from when we said this is something that “every single iPhone application developer should implement immediately“. If not sooner. That repository again, you can find it here.

But wait! There’s even more! If setting this up on your own server is too much of a strain — although it’s not that hard, really — it’s available as a free service online at macdevcrashreports.com! Or it will be, anyways; at present it’s in limited signup beta testing. Probably worth signing up with once they go commercial, I’m sure. In the meantime, the open source version works just fine. We’d call out “awesome” again, but “awesome” is running and crying from overuse in the post already, so we’ll just reiterate that this is something we’re going to consider mandatory for any future projects we’re actually going to be tasked with supporting after initial release!

Continue Reading →
Page 70 of 116 «...4050606869707172...»