
Mac apps are harder than iOS apps - mronge
https://medium.com/tech-blogging/614338e2e470
======
drewcrawford
So I have this question that's been eating at me for a few days, and I can't
find anybody who knows the answer and is willing to talk about it.

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.

~~~
terhechte
Not everybody who owns an iPad has or uses a hardware keyboard. I think most
people don't have one, and of those who do, many may hardly use it. I have a
bluetooth keyboard for my iPad, but I really hardly use it. I bought it once
for a longer vacation where I just wanted to bring the iPad but needed to be
able to quickly respond to mails. In the end, I didn't even use it much during
the vacation.

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).

~~~
drewcrawford
Yes, not everybody has a hardware keyboard, but at some point

    
    
         (large install base) * ( lower probability of having a hardware keyboard) > (small install base) * (certainty of having a hardware keyboard)
    

I'm interested in getting some kind of OOM answer to that equation.

> 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 ...

------
geuis
I have been working on a Mac app off and on for a few months. I don't have any
background in native programming though, as my experience has been pretty much
completely from web engineering and javascript/Python.

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.

~~~
mahyarm
I've learned to directly look at header files with apple code now-a-days. And
AVFoundation on iOS has a similar sparseness of documentation and community.
Also when you actually work with the code, you find out it's extremely
fragile.

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.

~~~
geuis
This is a good tip that I do more and more.

------
jlarocco
Most of these "problems" actually sound like good things to me. It's more
difficult to override stuff like the title bar for a reason.

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.

------
raimue
> On the Mac if you want to customize the window title bar, you are going to
> be in for a world of pain. Apple provides no API for customizing things like
> the title bar on OS X.

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.

~~~
shravan
Consider Google Chrome as an example. The title bar is customized to allow for
their tabs at the same height as the close, minimize etc. buttons.

~~~
sscalia
And that's precisely why I don't use Google Chrome - nonstandard Mac GUI (like
Google really has great UI? Please)

------
makecheck
Cocoa has actually evolved significantly. There was a long period on the Mac
where the (now legacy) Carbon and Cocoa APIs didn't overlap too well. In fact,
_both_ APIs had things that the other API couldn't even do, and _both_ APIs
had strengths in completely different areas. I think by about the time 10.3
Panther was released Cocoa had filled in a lot of the gaps, and Apple
eventually decided to not port Carbon to 64-bit at all. Carbon remains
functional but it's almost completely deprecated.

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).

------
programminggeek
Isn't this part of the reason why there's some effort to port some of the iOS
UIKit to OSX?
[https://github.com/BigZaphod/Chameleon](https://github.com/BigZaphod/Chameleon)

~~~
mronge
Yes, but most of these projects have been abandoned. GitHub for Mac used a
similar project but they've also changed direction. There is just too much
"stuff" to reimplement. It is really a job only Apple can do

------
CGamesPlay
I'm willing to bet that the next major version of OS X will do away with
AppKit and bring UIKit to the desktop. UIKit is already API-compatible in many
ways and most of the pieces are already in place.

~~~
terhechte
I'd be willing to bet against it. There's so much cruft that has to be kept in
for compatibility reasons that I really doubt it. Also, the Mac offers much
more functionality than an iPad, you'd need to expand UIKit a lot to run on
Mac hardware. Maybe they deprecate AppKit and introduce UIKit alongside, like
with Carbon, but I doubt they have the manpower for that right now. I guess
they'd rather concentrate on making UIKit better on ARM than porting it
somewhere else

~~~
zeckalpha
Isn't it already working on the x86? Isn't the iOS Simulator evidence of that?

------
outworlder
Good article.

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.

~~~
wolfgke
But WinAPI has excellent documentation on MSDN.

------
johnwatson11218
One thing that I found confusing about writing mac apps was the vestiges of
the old memory models. When I started a new project I just clicked the
checkbox for Automatic Reference Counting and assumed I was coding in
something like Java. I didn't think about memory management anymore.

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.

------
6cxs2hd6
"Why I'm not writing OS X apps", by Hipster Programmer:
[https://plus.google.com/u/0/107370779337689020644/posts/8SWf...](https://plus.google.com/u/0/107370779337689020644/posts/8SWfTAtS8LX)

~~~
Mikeb85
Hah! This is awesome.

------
PixelCut
Making custom OSX controls is easy with PaintCode
([http://www.paintcodeapp.com](http://www.paintcodeapp.com)). It is a vector
drawing app that generates Objective-C drawing code.

~~~
masklinn
His point is that you _have_ to create complex custom controls on OSX, whereas
in iOS it'll generally be sufficient to mix and match a few views and
CoreAnimation, and use customization options not present in OSX.

------
nikolakirev
The Layout is also a very tricky part. On iOS the app is always in full
screen. On OS X, there are infinite number of display sizes and the user can
dynamically change the size and ratio of the window of your app.

~~~
objclxt
Apple are pushing both iOS and Mac developers to use autolayout (especially on
the iOS side), which is meant to solve some of these problems.

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.

------
zulfishah
So true. I've been working on my iOS app for about 4 years now, and recently
started work on porting it to the Mac. But it's so much more tedious than I
expected, for exactly the reasons you mention: lack of documentation and
support, lots of subsystems to work on, legacy controls that aren't
customizable. Attending WWDC and talking to people on both AppKit and UIKit
teams, it's striking how little they seem to collaborate; it's like they live
in their own organizational bubbles, and there is very little push from on top
to make them more streamlined. They have made some progress on some frameworks
to consolidate them across Mac OS and iOS (MapKit comes to mind), but it feels
like they still operate as two independent entities within Apple; one being
the young hot-shot with all the resources, and the other being the envious
legacy-system that knows it's past it's best.

------
bengoodger
Desktop window manager integration seems to always be tricky. I've personally
sunk months of my life in getting a variety of custom window frames to work
"well enough" on various Windows flavors (for Chrome on XP, Vista, 7 and
newer). I think part of the benefit of these new mobile platforms is their
simplicity - there is less going on outside the app's control at any given
point in time, so there's less to worry about.

(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.)

------
joshdance
Good read. I like the examples. I have been thinking about writing some Mac
Apps. This made me rethink it. :)

~~~
lootsauce
Yeah I remember trying to emulate ios style scrollbars before they were added
to OSX. Yeah not so fun. Now if I had to make a Mac App I'd look into using
[https://github.com/rogerwang/node-webkit](https://github.com/rogerwang/node-
webkit)

~~~
astrange
Do you really care about customized UI so much that you'd rather ship a WebKit
view than not have any?

~~~
lootsauce
That's not the concern any more, it's just a fun and different way to make an
app. Im a web guy so its familiar territory and will be portable to other
platforms.

------
gdonelli
This guy has been writing Obj-C for 10+ years! woot!

