Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS Mac programming should be more like iOS programming.

M

moonman239

Cancelled
Original poster
Mar 27, 2009
1,541
32
My niche is iOS apps. I created a Mac project earlier, desiring to build an app that uses the Scripting Bridge framework. One thing about the Mac OS X SDK that I just don't understand is the lack of the ability to use storyboards. In iOS development, storyboards make designing the user interface easier if your app uses multiple view controllers. (For those of you who aren't familiar with iOS development, view controllers are like windows.)

So I want Apple to make developing for Mac OS X more like developing for an iOS-based device that has no touch screen and is capable of doing more than a real iOS device. Now, I'm not saying Mac apps should be more like iOS apps. I'm just saying, for example, that Apple should copy iOS's UIKit framework, strip anything that has to do with touch events, slap some "close," "minimize," and "enlarge" buttons on the UIViewController interface, and put that framework in the Mac OS X SDK. They can keep the NSApplications and NSWindows for all I care.

Yes, I plan to submit this to Apple, but I want to get some feedback from here first.
 
There already is a semi-clone UIKit work-alike framework for Mac OS X. But the UX is different enough that the result will seem crippled to a Mac-only user. Storyboards don't work when the user expects multiple windows all active.
 
I feel the opposite. iOS development should be more like Mac development. Maybe it's because I am more used to Mac development.
 
IMHO:

Apple has realized that the UI paradigm on mobile devices is not the same as on a desktop machine. At least not for "normal" Mac apps. That's why storyboards don't make sense for Mac apps.

Storyboards 'drive' the user experience which doesn't really apply to desktop-style computer use.

Maybe in the future they will make some sort of Window 8 style full-screen pseudo-mobile device interface mode. I won't use it, but maybe it will be there.
 
Storyboards don't make sense on OS X. In OS X apps, you have a lot of windows and panels and split views, because you have at least an 11" screen and often over 20", where the user has a tiny cursor that allows them to aim at pretty small elements. iOS, on the other hand, uses 3.5"-9.7" screens and relies on a huge cursor which limits how precisely you can touch, so you need to have a view stack, which lends itself to storyboards.

Feel free to drag multiple windows into a single .xib if you want.

If Apple wants to copy something from one platform to the other, Cocoa Bindings should be on iOS. They're neat when they work, but they're pretty much impossible to debug when they don't. I normally just avoid them.
 
It's definitely irking that one uses NSView and the other uses UIView, for example. I'd love to have more shared source code, and just having the same names would help.

There is a huge technical problem, and that is the iOS simulator that Xcode uses. The iOS simulator is an ordinary MacOS X application, containing a framework with its own versions of UIView etc. (So there is a UIView implementation for MacOS X available!) If UIView and NSView had the same name, the simulator would be in trouble. It would be very hard to keep the MacOS X NSView implementation separate from the iOS NSView simulation that apps in the simulator should be using.
 
I would say you have that slightly back to front. Many of the frameworks you use in iOS inherit from OSX. Leaning cocoa's frameworks first would be the optimum path as more controls become available under cocoa-touch, you will already have a head start. Apple, i think, are hoping to fuse the two together as much as possible but we are not quite there yet, not until we have one OS for both desktop and mobile.

I started with iOS first and like you, trying to make iOS apps work on OSX and figuring out the differences between AppKit and UIKit. NS... vs UI... etc

I was quite surprised though after getting past the storyboard vs xib/IB differences. Once you get your head around it, it all falls into place and becomes a lot easier.

Articles like this really help

https://developer.apple.com/library...ngFromCocoaTouch/MigratingFromCocoaTouch.html
and
https://developer.apple.com/library...erview/PortingfromCocoa/PortingfromCocoa.html

My first OSX cocoa app is coming along nicely, can't wait to get it on the App Store in a few months.
 
Last edited:
On the other hand, some frameworks came from iOS and eventually moved to OS X. AVFoundation comes to mind.
That being said, I do not think SpriteKit is an example: more likely it was developed in parallel on both both platforms. iOS just got released first.

Also, some OS X frameworks have been adding convenience functions to help with porting between the two. NSColor added functions identical to UIColor in 10.9.

And yes, I have found developing iOS apps more difficult with my limited iOS knowledge and more well-known OS X knowledge.
 
Anim said:
Apple, i think, are hoping to fuse the two together as much as possible but we are not quite there yet, not until we have one OS for both desktop and mobile.
Click to expand...

They've stated repeatedly that they're not heading that way.

They do, as much as makes sense, make similar or matching frameworks. IE, collections (arrays, dictionaries, sets, and so on) are the same on both. But they can't use the same responder system because one platform is built around a keyboard and mouse while the other is built around finger taps, and Apple has repeatedly stated that they won't be making a computer you can tap or an iOS device that needs a mouse/keyboard.
 
firewood said:
Microsoft has already tried that, using a desktop UI on tablets and a tablet UI on desktops. Look at their success in mobile compared to Apple's split UI. Buy M$ stock if you think they'll catch up.
Click to expand...

I think you misinterpreted what I was saying. The OS X UI should not be on mobile devices. From a developing standpoint I feel that OS X is more intuitive. Storyboards are confusing to me; I would rather go back to "classic" nibs.
 
Blakeasd said:
From a developing standpoint I feel that OS X is more intuitive. Storyboards are confusing to me; I would rather go back to "classic" nibs.
Click to expand...

You can create iOS apps without storyboards. Using "classic" nib/xibs and UI created purely in code are still fully supported iOS APIs. Thus many experienced iOS developers ignore storyboards, unless that design flow works out better for their iOS app.

And using a nib/xib based design flow may work out much better if you want to port a mostly single window app between iOS and OS X. Take the "root", "about", "prefs" and "help" view controller or UIView xibs from an iOS app, and port them to their own window controller nibs on OS X, while swapping in the closest equivalent NS/UI control elements.
 
firewood said:
You can create iOS apps without storyboards. Using "classic" nib/xibs and UI created purely in code are still fully supported iOS APIs. Thus many experienced iOS developers ignore storyboards, unless that design flow works out better for their iOS app.
Click to expand...

Count me in that camp. Storyboards and xibs seems pretty similar to me between OSX and iOS and differences are pretty irrelevant. Your layout is very likely to be different in iOS as OSX so GUI rework is needed regardless.

Like some of the previous commentators have mentioned, more overlap between how UI*** and NS*** operate would be helpful. Some behave essentially the same with just name changes, ranging to others being wildly different. One of the larger differences I have personally dealt with is with UIViews/NSViews and NSViews being layer backed or not, handling overlapping siblings, minor life cycle differences, etc.

All in all the differences are quite manageable and assuming your code is well designed makes reuse pretty easy.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back