Mac programming should be more like iOS programming.

Discussion in 'Mac Programming' started by moonman239, Feb 8, 2014.

  1. moonman239 macrumors 68000

    Joined:
    Mar 27, 2009
    #1
    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.
     
  2. firewood macrumors 604

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #2
    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.
     
  3. Blakeasd macrumors 6502a

    Joined:
    Dec 29, 2009
    #3
    I feel the opposite. iOS development should be more like Mac development. Maybe it's because I am more used to Mac development.
     
  4. mfram macrumors 65816

    Joined:
    Jan 23, 2010
    Location:
    San Diego, CA USA
    #4
    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.
     
  5. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #5
    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.
     
  6. gnasher729 macrumors P6

    gnasher729

    Joined:
    Nov 25, 2005
    #6
    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.
     
  7. Anim, Feb 9, 2014
    Last edited: Feb 9, 2014

    Anim macrumors 6502a

    Anim

    Joined:
    Dec 16, 2011
    Location:
    Macclesfield, UK
    #7
    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.
     
  8. Madd the Sane macrumors 6502

    Madd the Sane

    Joined:
    Nov 8, 2010
    Location:
    Utah
    #8
    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.
     
  9. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #9
    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.
     
  10. firewood macrumors 604

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #10
    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.
     
  11. Blakeasd macrumors 6502a

    Joined:
    Dec 29, 2009
    #11
    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.
     
  12. firewood macrumors 604

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #12
    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.
     
  13. MorphingDragon macrumors 603

    MorphingDragon

    Joined:
    Mar 27, 2009
    Location:
    The World Inbetween
    #13
    So you're asking for Windows 8 Metro Apps?

    Ask Microsoft how well that did for them.
     
  14. DaveP macrumors 6502

    DaveP

    Joined:
    Mar 18, 2005
    #14
    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.
     

Share This Page