6 ms·

Mac apps are harder than iOS apps

87 points by mronge 13y ago

programminggeek 13y ago
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 13y ago
  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
- victorf 13y ago
  If you've used both you can tell that UIKit is the version 2 or 3 of AppKit, there are many things where UIKit is pleasant to use and AppKit is irritating for similar things.
drewcrawford 13y ago
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 13y ago
  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 13y ago
    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 ...
- tl 13y ago
  The API that's available to iPads with keyboards is substantially different from the one available to Macs. 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.
  - drewcrawford 13y ago
    You'd be surprised. The method to detect chorded key combos isn't publicly documented, but that doesn't prevent e.g. http://panic.com/prompt http://panic.com/prompt from figuring it out.
joshdance 13y ago
Good read. I like the examples. I have been thinking about writing some Mac Apps. This made me rethink it. :)
- mronge 13y ago
  Ah go for it, it's still fun
- lootsauce 13y ago
  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 13y ago
    Do you really care about customized UI so much that you'd rather ship a WebKit view than not have any?
    - lootsauce 13y ago
      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.
- ZoFreX 13y ago
  I too have been thinking about writing some Mac Apps, as a way to learn ObjectiveC - with an intention to move to iPhone apps afterwards. This article has made me reconsider that ordering!
  - joshdance 13y ago
    I would start iOS. I started there and it has been great.
nikolakirev 13y ago
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 13y ago
  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.
CGamesPlay 13y ago
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 13y ago
  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 13y ago
    Isn't it already working on the x86? Isn't the iOS Simulator evidence of that?
- anandabits 13y ago
  I don't think they'll do that. I think their strategy is to see iOS replace OS X for most tasks and users. They will probably pursue a device somewhere between an iPad and a MacBook Air in doing this. 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/ 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-vacuum-or-ipad-pro/ 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...
- aufreak3 13y ago
  Why not go the whole nine yards and say "we're going to be using iOS on the desktop soon"?
- eddieroger 13y ago
gdonelli 13y ago
This guy has been writing Obj-C for 10+ years! woot!
PixelCut 13y ago
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 13y ago
  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.
johnwatson11218 13y ago
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.
- deleted 13y ago
  [deleted]
raimue 13y ago
> 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 13y ago
  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 13y ago
    And that's precisely why I don't use Google Chrome - nonstandard Mac GUI (like Google really has great UI? Please)
geuis 13y ago
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.
- wooster 13y ago
  The OS X dev community is much smaller than the iOS community. For questions like those above, I'd suggest the cocoa-dev mailing list: https://lists.apple.com/mailman/listinfo/cocoa-dev https://lists.apple.com/mailman/listinfo/cocoa-dev
bengoodger 13y ago
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.)
6cxs2hd6 13y ago
"Why I'm not writing OS X apps", by Hipster Programmer: https://plus.google.com/u/0/107370779337689020644/posts/8SWfTAtS8LX https://plus.google.com/u/0/107370779337689020644/posts/8SWf...
- Mikeb85 13y ago
  Hah! This is awesome.
jlarocco 13y ago
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.
outworlder 13y ago
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.
- therockhead 13y ago
  Agree 100%.
- wolfgke 13y ago
  But WinAPI has excellent documentation on MSDN.
zulfishah 13y ago
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.
deleted 13y ago
[deleted]
makecheck 13y ago
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).

87 points by mronge 13y ago

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 13y ago
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
victorf 13y ago
If you've used both you can tell that UIKit is the version 2 or 3 of AppKit, there are many things where UIKit is pleasant to use and AppKit is irritating for similar things.

drewcrawford 13y ago

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 13y ago
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 13y ago
  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 ...
tl 13y ago
The API that's available to iPads with keyboards is substantially different from the one available to Macs. 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.
- drewcrawford 13y ago
  You'd be surprised. The method to detect chorded key combos isn't publicly documented, but that doesn't prevent e.g. http://panic.com/prompt http://panic.com/prompt from figuring it out.

joshdance 13y ago

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

mronge 13y ago
Ah go for it, it's still fun
lootsauce 13y ago
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 13y ago
  Do you really care about customized UI so much that you'd rather ship a WebKit view than not have any?
  - lootsauce 13y ago
    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.
ZoFreX 13y ago
I too have been thinking about writing some Mac Apps, as a way to learn ObjectiveC - with an intention to move to iPhone apps afterwards. This article has made me reconsider that ordering!
- joshdance 13y ago
  I would start iOS. I started there and it has been great.

nikolakirev 13y ago

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 13y ago
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.

CGamesPlay 13y ago

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 13y ago
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 13y ago
  Isn't it already working on the x86? Isn't the iOS Simulator evidence of that?
anandabits 13y ago
I don't think they'll do that. I think their strategy is to see iOS replace OS X for most tasks and users. They will probably pursue a device somewhere between an iPad and a MacBook Air in doing this. 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/ 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-vacuum-or-ipad-pro/ 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...
aufreak3 13y ago
Why not go the whole nine yards and say "we're going to be using iOS on the desktop soon"?
eddieroger 13y ago

gdonelli 13y ago

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

PixelCut 13y ago

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 13y ago
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.

johnwatson11218 13y ago

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.

deleted 13y ago
[deleted]

raimue 13y ago

> 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 13y ago
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 13y ago
  And that's precisely why I don't use Google Chrome - nonstandard Mac GUI (like Google really has great UI? Please)

geuis 13y ago

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.

wooster 13y ago
The OS X dev community is much smaller than the iOS community. For questions like those above, I'd suggest the cocoa-dev mailing list: https://lists.apple.com/mailman/listinfo/cocoa-dev https://lists.apple.com/mailman/listinfo/cocoa-dev

bengoodger 13y ago

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

6cxs2hd6 13y ago

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

Mikeb85 13y ago
Hah! This is awesome.

jlarocco 13y ago

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.

outworlder 13y ago

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.

therockhead 13y ago
Agree 100%.
wolfgke 13y ago
But WinAPI has excellent documentation on MSDN.

zulfishah 13y ago

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.

deleted 13y ago

[deleted]

makecheck 13y ago

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