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
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.
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.
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).
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.
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 from figuring it out.
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
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.
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!
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.
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.
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.
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
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.
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...
That's really the last hurdle between ARM-based laptops, I think. If they can fully port UIKit, then expanding some of the concepts (like UIWindow) out would make it pretty easy to port an iPad app to an ARM-based MacBook. Or, have a special mode that runs iPads apps fullscreen, and problem solved. I would love a secondary machine the size of an 11" Air that ran for days on those massive batteries.
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.
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.
> 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.
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.
If they sorted all that shit out (which i entirely agree with) they might even pull some enterprise customers in from the Microsoft direction as well. The Cocoa framework is pretty nice compared to MFC and comparable to WPF. We played with the idea of knocking out desktop integration on OS X for our product as there is a huge uptake of apple stuff in our sector. We canned it in the end and suggested parallels as there just weren't many good resources out there to get over the learning curve and you just can't get anyone in the UK who can do it.
Despite all their warts otherwise, Microsoft do a pretty good job of this via MSDN.
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.
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.)
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.
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.
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).
47 comments
[ 3.0 ms ] story [ 111 ms ] threadWhen 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).
> 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.
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.
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...
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.
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.
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.
https://lists.apple.com/mailman/listinfo/cocoa-dev
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.
(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.)
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.
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.
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).