Native Mac apps can and should support full screen mode. Apple calls it providing users “with a more immersive, cinematic experience”. While there a a few apps that would not reap any benefit for the user taking over the entire monitor, there are some apps that can benefit from it greatly. In my case a productivity app like iCatalog Editor.
Last Friday I felt the time being ripe – after over a month of intense work – to roll out the first 1.0 version of iCatalog Editor. This Mac app is meant to revolutionize the work flow of creating digital catalog editions at my partner International Color Services. All those people who are are tasked with converting the raw material for paper catalogs into their feature-rich interactive digital counterparts where lacking such a tool for the past two years.
Not any more. Two years ago I had promised that there would be a Mac-based editor, but until now I was lacking the guts to dive into Mac development. I was afraid that my iOS development knowledge would not do me any good and that being an iOS development pro wouldn’t do me any good on the big intimidating Mac platform.
It turned out to be an unfounded fear. There are quite a few pitfalls, but I am pretty sure any experienced iOS developer can put together a good-sized Mac app in about a month or so. That’s what I did.
Development goes on, but from here on forth I will bunch fixes and new features together in releases that I need to push out to the guys and girls using the Editor app. Since it is sharply targeted at the unique needs of ICS I abandoned an earlier thought of putting it on the Mac app store. So how would I go about releasing the updates in a way that is as convenient as the app store, but would allow me to supply only the select group of Catalog Editors?
The answer to this question is: the same way most professional apps had been distributed before there ever was a Mac app store: Sparkle.
… well, almost. Of course you need to have both an SSD drive as well as an HDD drive present in your system. I just bought this Mac in April, 7 months ago. And of course I had gotten the dual drive option with a 256 GB SSD plus a 1TB HDD.
Manually having to manage what to place where is a pain. When I started to run out of space on the SSD I had moved my user folder to the HDD which was mounted at /Volumes/HDD effectively negating any speed benefit I would have gotten for working with my files. Like, for example, building apps since all my project files are located there as well.
Changing the Xcode temp folder wouldn’t net much of a measurable benefit as well, the bottleneck seems to be loading the project files from disk.
My heart jumped when I heard that Apple had invented the FusionDrive technology promising to end these managing pains.
I was procrastinating creating launch images for a several of my apps until now. Apple recommends that apps should have launch images that look somewhat like the app UI, but empty so that it feels to the user like the app is starting up faster. Because of the very same laziness I put a splash screen on one of my apps.
Splash screens made a little more sense back in the days when launching an app might take around 5 seconds, of if you where using a technique to artificially prolong the display of the launch image and then have it animate away, like DTSplashExtender. In the very rarest of cases you need a splash screen if there is some legal stuff you want to get off your chest before letting the user play with the app.
Of course most professional developers would have the launch image be also created by their designer. I cannot afford such an extravagance, so I came up with the quick method I am describing in this blog post.
In the blog post before this one I began my investigation into TCP connectivity and Bonjour. I set out to create DTBonjour as part of my DTFoundation set of tools to make communicating between Macs and iOS devices extremely easy.
Then I spent a couple of hours on putting together a proof-of-concept app that would show me what’s still missing on the API. Having some classes disconnected from real life use is quite a different ballgame than actually showing it in action.
I asked on Twitter for some suggestions what app to make to show this off, but all where way more involved than the example that I finally decided on: a simple Chat app.
For my Mac-based iCatalog Editor app I am developing a preview mode that allows for on-device previewing of iCatalogs. This is modeled after the Preview mode in iBooks Author with the tiny difference that there Apple restricts the preview feature to iPads connected via USB, which we will be using the full power of Bonjour to use any app that is running our specialized iCatalog Viewer app on the local WiFi network.
Apple has done a great job making service publishing and discovery a breeze. However they are severely lacking in the object-oriented Sockets department. in this blog post I’ll be developing an Objective-C library that will greatly simplify the process of finding, connecting and communicating with other devices.
And since we are developing for iOS and OS X in parallel the resulting code will work on Mac and iOS devices just the same.
For the toolbar in my iCatalog Editor Mac app I wanted to have have a toolbar button that would show a drop down menu for selecting what kind of hot zone the user wants to insert. iBook Author has a button like this and I was searching for way to get a similar look.
AppKit does not have this as a standard component, but I found two approaches that would yield a similar looking result.
For an inspector panel I wanted to have a horizontal collection view contained inside a vertical inspector scroll view. The vertical scroll view would only scroll if the window was too small to show all sections in the inspector.
The problem there is a NSScrollView gobbles up all scroll wheel events if the mouse pointer is on top of it. Here’s a solution how to have it selectively forward the scroll events up the responder chain.
Do you remember, back when you first opened Interface Builder?
How long did it take you to understand the purpose of File’s Owner?
That is a proxy for the object that loads this NIB, usually a UIViewController. This allows you to connect IBOutlets and IBActions with elements contained in the NIB file. IB knows about these because you tell it what class the File’s Owner has and from parsing this class’ header it finds all things that you can connect to by the IBOutlet and IBAction keyword.
That one was easy. Second question: How long did it take you to understand the purpose of First Responder?
If you are like me then you started out developing for the iPhone and other iOS devices. And then you probably also learned to ignore this proxy object because on iOS it does not serve an obvious purpose. In fact you can go for years developing iOS apps without ever doing anything with it. I know I did.
It is only know that I am starting to dabble in developing for the Mac that I had to begin to develop and appreciation for the responder chain. And so finally I understand the purpose and usefulness of the “First Responder” object and I want to share this with you.
… no, were not talking about the kind of fun that burns when taking a leak. In this article I want to summarize what I learned over the past weeks about working with Universal Type Identifiers.
On Windows files where always only identified by their file extension. In the olden days Apple was using multiple additional methods of determining what to do with certain files, amongst them HFS codes and MIME types.
The modern way to deal with file types is to use UTIs which are typically a reverse domain name, like “public.html” for a generic HTML file or “com.adobe.pdf” by the PDF type created by Adobe. UTIs have an additional advantage that other methods of identifying types do not possess: a file can actually possess multiple types.