While I am developing my first own Mac app I’ve been adding to this blog post whenever something was weird to me. Or simply different.
You can definitely see in many instances how some modus operandi on iOS has its roots on Mac, but Apple had to change things a bit around to accomodate the different UI paradigms on the mobile platform.
This maintenance release for Linguan fixes a number of issues which where mostly reported by our users.
Changes
Also we had to add a beautiful Retina icon for Retina MacBook Pro to be able to submit the update. It’s in Apple’s hands now and we will update this post as soon as it is through review.
We have to keep our fingers crossed because due to the way Linguan uses the xcodeproj it cannot be (easily) sandboxed. Though Apple had stated that they will accept minor fixes (like the ones mentioned above) for updates. We sincerely hope that they will honor this.
Update Oct 6th: Apple approved the update after 24 days. You can get it on the app store.
Notice: The following text is a rant and entirely my own opinion, not being a lawyer by profession, but a developer at heart.
Over the past month or so I was negotiating with a US-based company who wanted to retain my services as an expert on Rich Text and HTML parsing. Let me share a problem I had with a certain section in the contract that I was asked to sign, a problem that related to my previously created code and for-pay components.
Even experienced developers might be overly anxious to sign their next big contract to put food on the table without knowing what rights in their works they are signing over by this. This should serve as a gentle reminder: Better to read through the contract, all 19 pages of it, than having to be afraid that you inadvertently giving away your crown jewels.
If I learned one thing from Steve Jobs then it is to not trust contracts that are longer than a single page …
One of the first lucky owners of the iPhone 5, David Smith, kindly ran my Image Decompression Benchmark on the latest 3 generations of iPhone. These benchmarks measure the time it takes for an image to get from disk to screen and encompass 5 resolutions, PNG crushed and uncrushed, as well as 10 compression levels of JPEG. Christian Pfandler prepared the charts for us.
We like to repeat the same benchmarks on every new CPU that Apple likes to solder into their devices, you can read past analyses iPhone 3G through iPad 2, iPad 3. One note of caution if you want to compare these to the results in this article, we changed the methodology of logging the times from NSLog to CFAbsoluteTime. NSLog itself takes up to 50 ms per logged statement. The new method is more exact and does not have this drawback of including the logging time in the measurements.
Executive Summary: the iPhone 5 can indeed be claimed to be twice as the predecessor.
Hot on the heels of my research into the responder chain comes this bug report. Nikita Korchagin deserves the main credit for mentioning this first to me.
Turns out that Apple broke the responder chain as it used to work on Mac and non-storyboard apps. I’m filing this as a bug report to find out if this indeed a bug or an “undocumented feature”. rdar://12402078
Update Oct 5th: Apple closed this as suplicate of rdar://12395544
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.
This is one of those rare jewels of a bug that will cost you days to figure out if you encounter it in the context of a large app. It makes you doubt our own sanity until you come to the painful conclusion that the problem indeed resides in Apple’s code, not yours.
In this special case we had a couple of rare circumstances that worked together to form a scenario where CGRectMakeWithDictionaryRepresentation partially fails to reconstitute a CGRect from a dictionary. This function is literally ancient, it exists since iOS 2 and Mac OS 10.5. This makes it even more implausible that nobody has stumbled across this before us.
In the project where we first saw the problem these where the steps that led to this bug’s discovery:
What’s even funnier is that some such modified values can still be read, but then the function fails internally and the remaining values don’t get parsed, i.e. stay zero.
From what I have seen researching this bug looks like certain floating point numbers cannot be represented on iOS. The normal parsing functions are able to round to the closest value that can be represented in 32-bit floats, whereas CGRectMakeWithDictionaryRepresentation fails to do so. The first value that cannot be exactly represented is truncated, all following values turn out to be Zero.
This was filed as rdar://12358120 and on OpenRadar.
I made some updates recently that I wanted to mention so as to minimize some surprises. Also there are some changes that were prompted by iOS 6 being released.
The great thing about building apps for both iOS and Mac is that many pieces of code work just the same on both platforms. There are some scenarios however where you want to add different kinds of Apple SDKs based on which platform you are building for.
A good place to put all headers that often used is the Precompiled Header File (PCH) which gets precompiled and then reused throughout your app. Whenever you have an #import statement in your code the compiler needs to figure out whether this header has already been imported because the same header file can potentially be imported from several locations.
I generally like to put all imports for Apple headers into my PCH file as well as my own app-wide classes like my DTFoundation library which has a growing selection of methods that I frequently use. Having these imports in the PCH means that the preprocessor can prepare them for faster compiling once and then can virtually prepend all these definitions for every source code file.
Today I learned something new, namely how you can use the same PCH for Mac as well as iOS.
License:
