I recently gave a brief talk at the Cocoaheads meeting in Vienna. This is a summary.
The nice folks at GitHub released an open source model layer for iOS and OS X applications that they initially developed for their own GitHub OS X app. They called it Mantle.
Usually Core Data is the obvious choice as a model layer since it’s developed by Apple and therefore tested and well documented. However, it does not fit every use case. Especially if a lot of objects are written at once, Core Data gets painfully slow and also freezes up your user interface when the
NSManagedObjectContext of the main thread synchronizes with another one.
To have better control over the performance one could opt to use SQLite directly, as it was actually required back in the dark days of iOS 2, when Core Data was not available for iOS yet. Since direct SQLite access involves a lot of boilerplate and ugly C function calls, a framework like FMDB could help.
However if you don’t have the need for complex SQL queries and only want to fetch and display data from a JSON API, Mantle is an ideal tool. Alternatively, it could also be used as an adapter between the API data and your Core Data
[ Continue reading… ]
UPDATE, Jun 2013: Apple finally made it possible to easily transfer apps between accounts. Just go to the app in iTunes Connect and choose “Transfer App”.
The short version: It’s not possible.
The backstory: In July of 2012 I started my current job at KURIER.at after they aquired the services of a company I used to work for. Among them film.at, one of Austria’s biggest movie platforms, for which I built the iOS app.
Obviously we wanted to transfer all the existing apps to the Apple account of KURIER.at. Reports stated that Apple does not allow this, but I had hope since those where over a year old and our current scenario seemed like a very common one. So I contacted Apple.
[ Continue reading… ]
It is easiest for me to learn about things gradually. If I am interested in a new area I start following various blogs and people on Twitter who are engaged in that field. My usual approach is to follow every resource that I can discover. I always have the option to delete them from my feeds if they proove to be of no interest to me.
However, it is not always easy to discover these resources and I am always happy to find a good starting point. So I decided to share the resources that I find helpful for various fields. These links might seem obvious to people already interested in these areas, but I do hope that they will be helpful for someone new to the game.
Free free to leave suggestions in the comments if you think that I missed something important.
[ Continue reading… ]
Every iOS user knows this: Apps crash. These crashes are usually the developer’s fault and some are pretty nasty and hard to track down in a development environment. Therefore, it is very useful to collect crash reports from apps that are in production.
Fortunately, there are tools out there that do exactly that. My weapon of choice is Crashlytics. Other options are Hockey and plcrashreporter.
The way Crashlytics works is that an OS X app has to be installed and has to run in the background every time a build of an app is made in order to upload its information, like the .dSYM file, to their service. Xcode connects to the Crashlytics app through a run script. The whole setup process is done quickly and the Crashlytics app provides a very good guide. I do not like the fact that a dedicated app has to run in the background but in the end it is convenient.
Crashes are visible through an online dashboard that shows every piece of information that one might expect: Number of crashes, affected app versions, stack traces, and detailed information about the devices (e.g. iOS version, free RAM, jailbroken). E-mail notifications and integration into other services like Jira are also possible.
I have been using Crashlytics for a few months now and it has proven itself to be very useful. It collected various crash reports that I never saw during the development phase.
The service is currently free but they will announce a pricing model in the near future and I will be happy to pay. Every serious developer should collect crash reports to ensure the quality of their shipped apps.
Backups are important and should obvioulsy not be stored on the same server. Sending a dump of my PostgreSQL database per e-mail once a day seemed like an easy and viable solution – as long as it does not get too big. Gmail accounts provide more than enough space for storing small backups which is why I set up an additional account in order to not pollute my main inbox.
This is the small script I wrote to do so:
pg_dump --inserts $DATABASE | gzip > $FILE
mutt -s "PG Dump $DATABASE $DATE" -a $FILE -- $EMAIL < /dev/null
You might have to install and configure
mutt to be able to send e-mails with attachements. This tutorial shows how to do that.
Store the file somewhere, execute
chmod +x pg_bak.sh and schedule the script as a cronjob via
# m h dom mon dow command
0 4 * * * /path/to/script/pg_bak.sh
Now a backup of your database should be sent to the provided e-mail-address every day.