Computing / ios / mobile1 Comment
Feb 12

XCode iOS simulator is case insnsitive. iOS on Device is not.

We have an iPad app. We load images using file paths into the app. Images appear just fine in the iOS simulator. Images do not show up on the device. Fist shaken madly in the air, agony.

Thanks to my colleague Dolphy Fernandes we managed to discover the culprit. The iOS Simulator used by XCode loads file in a case insensitive manner. To it, a file called A55.jpg and a55.jpg are the same. iOS on devices, on the other hand, is case sensitive. Hence, A55.jpg will not load if the file name you are attempting to load is 'a55.jpg'.

Hope it helps…

Sep 11

Xcode: “No match for certificate/private key” error and resolution

An app we were building for the iPad was recently approved by the client. Being a more capable organization, the client wanted us to build the app for them using their Apple developer and app store credentials for submission. To do that they sent us the three necessary files:

  • Public Key (Distribution)
  • Private Key (Distribution)
  • Mobile Provisioning Profile (Distribution > AppStore)

I also modified the app's bundle identifier to reflect the identifier specified by the client.

I merrily added the keys and certificate to the OS X key chain. Yet Xcode was unable to build using these updated credentials. The error that was reported was:
"Profile does not match any valid certificate/private key pair in the default keychain"

After digging around I pinged my friend Glenn Martin from Intrepid Development to see if he knew what was wrong. Glenn actually knew what went wrong: apparently OS X 10.6.8 imports keys to the System key chain instead of the Login key chain. Xcode only looks at the Login key chain. All the was necessary to fix the issue was to drag and drop the key in the Keychain Access application from the System key chain to the Login one. Mindless fix to a truly frustrating problem.

Hope it helps you.

Aug 11

SQLite ORDER BY does not work on integers: time for an index

My current project uses SQLite as it is really the only game in town on iOS. SQLite indexes provide an incredible performance boosts when you are dealing with large datasets. They apparently play a crucial role when it comes to something of a foregone conclusion in other databases – sorting.

What stumped my colleagues and I was that we had a database table where one of the columns had an INT (and also tested using an INTEGER) type (and yes – they are all NUMERIC to SQLite) – and ORDER BY kept returning incorrectly sorted results. According to this post on Stack Overflow, when you have a SQLite query that uses the ORDER BY, it may rely on temporary tables. Those in turn 'confuse' the database when it runs the query to sort your table.

The answer – add an index. Something as simple as

CREATE INDEX index_name ON table_name

Once you add it – you are, well – sorted out.