Mac apps are harder than iOS apps
medium.com
medium.com
When I find myself wanting to write Mac (as opposed to say iPad) software, it is not always but usually because having a hardware keyboard is important to whatever software I want to write, and of course all Macs have hardware keyboards. There are other reasons, like better interoperability with other desktop software, but these seem to shrink each year.
But it occurs to me that with iPads outselling Macs at a ratio higher than 4-to-1, it seems at least plausible to me that either there are, or could be in the forseeable future, more iPad users with hardware keyboards than Mac users. So if you are trying to target people who use a keyboard, the iPad could be a better bet.
I can't find any numbers so I don't know if we are there already or if we are a long ways off. But this line of inquiry has really caused me to question whether the iPad makes more sense than the Mac for a lot of projects that I have formerly just assumed would be a better fit for a desktop form factor.
What kind of apps, except for text processing like word, number processing like excel, programming editors, or scientific like mathmatica are you thinking about? I think these are the categories where keyboards are really necessary for iPad, but for all others, I think touch input may be the better option (I'll probably have forgotten a couple of niche categories, like music trackers).
(large install base) * ( lower probability of having a hardware keyboard) > (small install base) * (certainty of having a hardware keyboard)
> what kind of apps... are you talking about?
Well for example, here I am, at this moment, typing a comment to you on an iPad with a hardware keyboard.
But to answer your question: heavy email, threaded discussion, bug reporting, data entry (e.g. invoices, grades, tracking numbers, door-to-door, consumer surveys, medical coding, pilot logbook, etc), inventory management, insurance adjusters, real estate listings, pro-grade eBay/Craigslist tools, non-casual games (e.g. Starcraft, Half-Life, etc.), Quicken, MSProject, TurboTax ...
If your Mac software relies on keyboard behavior that third-party apps cannot produce (like CMD+C doing a logical copy of a selected item instead of copy this text) it may not matter how many iPads have keyboards.
My biggest issues have been 1) Lack of a development community and 2) Both too much documentation and not enough.
1) The Mac dev forums from Apple are almost dead. Asking a question on StackOverflow is a literal crapshoot as to whether you'll get an answer or not. I don't know where to begin looking for an active, vibrant Mac developer community.
2) Apple's documentation is simultaneously rich and deep while being incredibly sparse, inconsistent, and maze-like. Very frequently you can find a description on SO or a blog post referencing something you need, yet the link is broken because Apple is very bad about maintaining and forwarding links when they change their URL structure.
There are entire classes of questions that I don't even know how to research or ask about yet I know should have answers when I encounter them.
Not too long ago I was doing something with AVFoundation. There was a particular setting that I needed to change, and by looking at the signature of a similar feature that plugged in the same way I knew it should be there. But I couldn't find it. The docs in this feature said nothing about it. I searched high and low for 2 days for sample code or anything that implemented this thing. I was getting nowhere.
I finally went back and watched the original 2 WWDC videos where AVFoundation was being introduced in 2011. After 2 hours and literally in the last 2-3 minutes of the 2nd video, the speaker casually mentioned the feature I was working with. I about flipped my lid at that point.
The property was exactly where I expected it. Xcode wasn't autocompleting it for some reason and I think there was a camel-case issue that was making it fail. All in all it was extremely frustrating.
I'm being vague about the details because this all happened about a year ago and I haven't thought much about it.
If anyone knows if/how you can display a window in the app while recording the screen with AVFoundation and not record that window, you'd save me a ton of time and frustration. Otherwise I fear I have to stop using AVFoundation and do my own implementation which I think is a very bad idea.
Despite all their warts otherwise, Microsoft do a pretty good job of this via MSDN.
This is why you want to be able to see source code in your libraries, you can solve these kinds of problems a lot better.
Mac apps aren't iOS apps, and if you're developing them as if they are, you're app is going to look goofy and ugly running on OSX. Your app isn't as special as you think; it should use the standard conventions like everybody else.
That said, there are a very few apps where going away from the conventions can work. Lightroom comes to mind, but there might be others. In any case, it only works if it's done all the way and not half assed, which I'm not sure 99% of software companies are capable of doing. If Adobe wasn't a mega-corporation with tons of money to throw at it, they'd probably screw it up.
That is not really a downside. Why should the title bar be customized by an application? The title bar is used for the window management by providing controls to close, minimize, resize, and move the application window. This behavior should not be customizable by the application at all.
As great as versions like Mac OS X 10.3 were, later versions of the Cocoa API are noticeably better. In fact, it's now hard to support anything earlier than 10.6 because of improvements to libraries (e.g. more native UI views available, more features per class), improvements to the compiler and other developer tools (e.g. ARC), and changes to the language (e.g. blocks).
As of Mac OS X 10.8, the Cocoa frameworks are decently in line with iOS, far beyond the simple stuff like NSArray; for example, AVFoundation.framework and GLKTextureLoader now exist on both platforms which is useful for consistent game development.
Cocoa is also more customizable than you might think. While technically Cocoa won't allow certain view or window properties to change, an illusion of a change can be just as effective and is straightforward (not to mention being more stable for the OS in the long run). For instance: maybe you create a mostly-transparent borderless window at a specific location with a certain Z-order, in which you draw what looks like a window frame modification; this is often exactly what is required even though the window underneath didn't actually change at all.
I have my own share of frustrations with Cocoa in spite of what I've said. Cocoa is not perfect and I do think they still have some work to do in terms of improving sync with iOS and making it a lot more powerful. A pet peeve of mine is that APIs often lag far behind new OS features (e.g. new UI paradigms...it seemed to take forever for Spaces to be properly handled in the API).
Robert Cringley thinks this will be a display and input device that connects to a phone: http://www.cringely.com/2013/09/19/the-secret-of-ios-7/
I think it will be a standalone device: http://anandabits.com/blog/the-secret-of-ios-7-macbook-vacuu...
The most interesting piece will be to see how Apple approaches this form factor without creating a "refrigerator toaster". I'm optimistic that we'll find out in less than a month...
Now, try the Win32 API, then go back to Cocoa. That will put the "pain" into perspective.
OSX developers are writing at the same level as C developers using Win32 directly, but with a much nicer, object-oriented API.
I remember having to add annotations to the auto generated getter/setters to inform old memory management systems how to treat things returned from the methods (I'm sure I stated that incorrectly but it has been a while). Bottom line is that it was hard to know what was no longer required when coding with the latest release. If I read tutorials that were a few years old they would confuse me with aspects of memory management.
I say 'meant to' because autolayout is far from perfect, but there's a pretty clear shift on the iOS side from a "code to a fixed 320x480 window" to a "write a UI that can adapt to different sizes gracefully". For example, apps should in iOS 7 really now be able to handle varying text sizes (and thus layout) according to user preference.
(On Windows, there are several ways to achieve a "custom-ish" frame, but only if you really study the window manager-app interaction and think about the problem as if you were the window manager can you come close to doing a proper job of it... handling the right messages (some of which are undocumented and only discovered via using spy tools), responding in the correct way etc.)