Slashdot Mirror


Apple Brings iOS Apps Into Mac, But Won't Merge Platforms (cnet.com)

Stephen Shankland, writing for CNET: With its next-generation MacOS Mojave software, Macs will be able to run some apps written for iPhones and iPads, a big new step in bringing the two technology platforms closer together. Craig Federighi, Apple's senior vice president of software engineering, announced the change Monday at Apple's Worldwide Developer Conference in San Jose. And he said Mojave will include four apps Apple itself brought from its iOS mobile software to MacOS: Home, Stocks, News and Voice Memo. "There are millions of iOS apps out there, and we think some of them would look great on the Mac," Federighi said. For now, it's only Apple that has the ability to move iOS apps to MacOS. But that'll change in 2019.

46 comments

  1. for how long? by fred6666 · · Score: 1

    for how long?

    1. Re: for how long? by saloomy · · Score: 1

      Forever, unless stated otherwise.

  2. Home, Stocks, News and Voice Memo!! by Anonymous Coward · · Score: 0

    aw shit son, it's the 4 apps i delete first when i get a new idevice

    1. Re:Home, Stocks, News and Voice Memo!! by Bing+Tsher+E · · Score: 1

      Things have clearly changed. Back when I had an iPod Touch it wasn't possible to remove icons you didn't want. You had to shove them into a folder and put it in a corner of a page somewhere.

    2. Re:Home, Stocks, News and Voice Memo!! by Anonymous Coward · · Score: 0

      I'm not your son.

  3. Not entirely accurate by Anonymous Coward · · Score: 0

    iOS Developers will be able to port their apps to macOS.

  4. I'll Settle for Plants vs. Zombies II by Anonymous Coward · · Score: 0

    iOS but no Mac version? it's too hard to play on a small iPhone screen.

    1. Re:I'll Settle for Plants vs. Zombies II by cfalcon · · Score: 1

      paraphrase: "Plants vs. Zombies is too hard to play on a small screen"

      I think this is how they sell you an iPad :/

  5. Bait and switch 101 by Anonymous Coward · · Score: 0

    Quite obviously the aim here is to go in stages such that, one day, Apple start a WCDC event with what looks like a mac on the stage, and a casual chat about how great the Mac is. And then Tim reveals, "... but this isn't a MAC, this is being driven - magically - by my iPhone!" ... and suddenly 1 billion users around the world have a PC in their pocket.

    1. Re:Bait and switch 101 by ChunderDownunder · · Score: 1

      And a lone Windows 10 Phone user will cry "but we had that way back in 2015!"

  6. Why not just include an emulator? by jandrese · · Score: 1

    How hard would it be for Apple to include an iOS emulator for the Mac that could run regular iOS apps? Sure it's a different instruction set, but that's a long solved problem. They even have the big multitouch trackpad so you don't have to work too hard to emulate gestures. I'm pretty sure they already have this for developers, so it shouldn't be that hard, although I'd prefer it if they put in a little effort to make it seamless on the desktop. You could install an iOS app just the same as a regular Mac app and launch them with double clicks just like you would with any app. I bet it would see a reasonable amount of usage.

    --

    I read the internet for the articles.
    1. Re: Why not just include an emulator? by Anonymous Coward · · Score: 2, Informative

      They have an emulator in XCode. However, the user experience is terrible, and that's the value that Apple brings - a user experience that doesn't completely suck.

      By bringing frameworks and APIs closer together, it allows the developer to make an app people would actually want to use, instead of some garbage emulated not-quite-right touch UI that barely works, otherwise known as Windows 8.

    2. Re:Why not just include an emulator? by DontBeAMoran · · Score: 3, Insightful

      There's no guarantee the computer has a trackpad because of the Mac mini, iMac and Mac Pro.

      --
      #DeleteFacebook
    3. Re:Why not just include an emulator? by Chelloveck · · Score: 2

      There's no guarantee the computer has a trackpad because of the Mac mini, iMac and Mac Pro.

      There's a lot you can do without multitouch, though. Most things I do on my phone could just as easily be done on an emulator with a single traditional mouse pointer. Make the emulator treat the scroll wheel (or modifier key + scroll wheel) as a pinch/stretch zoom gesture and that'd cover almost everything.

      --
      Chelloveck
      I give up on debugging. From now on, SIGSEGV is a feature.
    4. Re:Why not just include an emulator? by Anonymous Coward · · Score: 0

      Yes, developers can emulate an iOS device. But it sucks and is basically unusable. If you want to develop in practice you need a device to run the app on -- you can tether it and get all the instrumentation you need for debugging.

      So while the "different instruction set" may be a long solved problem what isn't is getting things to run with usable performance. Remember, you aren't just emulating an ARM CPU, but an entire system. While an iOS device has nothing close to the performance of a desktop or laptop it is good at what it does and emulating different destroys the optimizations relied on for performance on the host.

      Back in the day you could emulate a PC on an Amiga with emulation -- but the performance lagged so bad it was essentially unusable for anything more than DOS. For a while there was actually a product consisting of an x86 board you could slot into an Amiga because having the hardware was essential for performance.

      The only time I've seen high performance emulation really work was Amithlon -- that was a custom linux kernel whose sole purpose was to run a 68k JIT emulator. By then the performance gap between Amiga hardware and PCs was so great, and the efficiency of Amiga applications was so great*, that you could have a (comparatively) screaming fast Amiga emulation.

      * For example, Amiga's had just a few MB of RAM, but were so efficient that memory wasn't really an issue. Even bloated applications were (compared to Mac/linux/Windows) incredibly small. A full featured web browser was less than 1MB in size. Their most obvious failing was graphics which, due to dependence on a custom graphics chip set, had fallen generations behind the rest of the computing world. From a "whole system" perspective it was "cheaper" to emulate than linux (or even Windows) because it was an entirely single user system without any security (e.g., every application had full access to memory).

      In short, while an iOS device has more powerful hardware than Amiga it has a whole lot more responsibility and security -- compartmentalization comes at a cost.

    5. Re: Why not just include an emulator? by Yaztromo · · Score: 1

      They have an emulator in XCode.

      Technically they have a simulator. When you build your Xcode project, it is actually compiled twice: once for the target iOS device, and once for Intel x86_64. When you run your code in the simulator, it's running native Intel code, and not emulating the iPhone/iPad processor as in a full emulation environment.

      It's worth being aware of the subtle differences. You can get huge performance increases in your code in the simulated environment, as you effectively have full access to the x86 CPU's processing capabilities. For this reason on-device testing is still very important.

      Yaz

    6. Re: Why not just include an emulator? by Arnold+Reinhold · · Score: 1

      Appleâ(TM)s emulations of the 68000 on the PowerPC and, later, the PowerPC on Intel worked quite well. They also had tools for distributing a program with separate binaries for different platforms. No doubt they can dust them off to distribute apps for both ARM and x86 when the time comes. Apple seems to be taking their time to think this through, which is wise.

    7. Re: Why not just include an emulator? by Midnight+Thunder · · Score: 3, Insightful

      Merging the experience in a way that doesnâ(TM)t force the developers to think of the different interaction results in things like Windows CE or Windows 8.

      Importing an application in this context can be easy, by ensuring the best user experience for a given device is another story.

      --
      Jumpstart the tartan drive.
    8. Re:Why not just include an emulator? by Anonymous Coward · · Score: 0

      Given the current quality of Apple code, I would expect an open source Rosetta-style emulator well before the iApes can figure out how to stop scratching their asses.

    9. Re:Why not just include an emulator? by BasilBrush · · Score: 1

      Already tried it. There's a simulator in XCode that does exactly that. And it makes for a terrible user experience.

      What Apple are doing now is the right approach for user facing apps. Make iOS apps compilable for OSX, but allow for changing the things that are different on the desktop OS. Like resizable windows, typing and editing with a real keyboard, target sizes suitable for mouse pointer rather than finger, different transitions, a menu etc.

    10. Re: Why not just include an emulator? by BasilBrush · · Score: 1

      I don't think there's any need for fat binaries. The App Store and The Mac Store are separate places. Different download for users, different upload for developers.

      Same XCode project for both, same code, compiling for 2 different targets.

      A developer would probably want to deliver them on a different schedule anyway. Different testing plan. And quite likely different bugs to fix.

    11. Re:Why not just include an emulator? by ChunderDownunder · · Score: 1

      Last I visited an Apple store, the iMacs were controlled by those magic touchpad things.

    12. Re: Why not just include an emulator? by bondsbw · · Score: 1

      Actually Apple is doing pretty much exactly what Windows 8 did, since WinRT was a set of universal APIs with targeted compilation. There was no emulation involved.

      Sure it sucked, but it's hardly fair to compare Apple's 2019 vaporware with an OS Microsoft released back in 2012.

      --
      All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
    13. Re: Why not just include an emulator? by Anonymous Coward · · Score: 0

      I always thought XCode was Apple?

    14. Re: Why not just include an emulator? by jandrese · · Score: 1

      The problem with that emulator is that it emulates an entire phone screen, not just one app. There's no OS integration which makes for a terrible experience.

      --

      I read the internet for the articles.
    15. Re:Why not just include an emulator? by Plumpaquatsch · · Score: 1

      I have a Mac app directly hand-ported from iOS years ago - and there's clearly something missing. It would certainly not be better with automatic porting or emulation.

      --
      Of course news about a fake are Fake News.
  7. Does it have dll hell? by stroxor · · Score: 0

    Dos driver development was great time in comparision to this.

    1. Re:Does it have dll hell? by BasilBrush · · Score: 2

      No. There's no point in sharing libraries between apps in this day and age. Storage devices are large, and code binaries are relatively small.

  8. Sad by Anonymous Coward · · Score: 0

    If their computers and laptops ran iOS, maybe they'd get more frequent hardware refreshes. Like the iPhone does.

    1. Re:Sad by Anonymous Coward · · Score: 0

      Why do you think they're ditching Intel for ARM?

    2. Re:Sad by Anonymous Coward · · Score: 0

      Why do you think they're ditching Intel for ARM?

      They aren't, not any time soon at least. The migration to Intel from PowerPC worked because Intel's chips were so much faster that they could easily emulate the PowerPC chips and native code didn't suffer any performance hit, likewise with the transition from 68k to PPC.

    3. Re:Sad by Bing+Tsher+E · · Score: 1

      Why do you think they're ditching Intel for ARM?

      Good question. Why would anybody think that?

    4. Re:Sad by Anonymous Coward · · Score: 0

      Why do you think they're ditching Intel for ARM?

      Good question. Why would anybody think that?

      If this isn't irony/sarcasm - because by doing so Apple brings control of the entire stack in-house. Apple has a tendency to do this (control the design of everything in their product, with actual manufacturing being the only thing outsourced). The i-devices are able to do match and exceed performance of Android devices with lower clock speed and RAM because of this. Intel performance seems to have hit a wall, the advantage of remaining in the x86 ecosystem is fading.

      Actually you don't even have to look at Apple - even Microsoft is extending into the ARM space.

      (heh, and Intel calls their CPUs "core"... anybody played Total Annihilation? Core vs. Arm!)

    5. Re: Sad by Bing+Tsher+E · · Score: 1

      Apple has never use an in-house processor for their Mac. The last time they came close to doing so with the PPC it turned into a disaster they had to abandon. So it's hard to say it's something Apple tends to do.

    6. Re: Sad by Anonymous Coward · · Score: 0

      The Mac is no longer Apple's primary product.

      Look to the iPhone for what's representative of what Apple does.

      What apple does with the iDevices is what represents Apple's tendencies. They've been taking things more and more in-house there.

    7. Re: Sad by Anonymous Coward · · Score: 0

      apple is a small player in the PC world

      they didn't design their chips for the mac because the volume was too low

      when it is worth it they make their own

      apple A11 outperforms PC class CPUs:

      https://www.businessinsider.sg...

      they are ready

  9. The Xcode Simulator Works Well by glennrrr · · Score: 2

    As a long time iOS developer, I disagree with your assertion that you need to be constantly tethering a device. I do 90% of my work via the simulator, and only hook up a device when I'm debugging gestures or other similar features late in the development cycle when I want to make sure the user experience is good.

    1. Re:The Xcode Simulator Works Well by BasilBrush · · Score: 1

      Agreed. I'm the same.

      But it depends what sort of app it is. Motion, GPS, Games, Camera, VR etc, you probably do want to use device rather than simulator. And it doesn't take much longer to do so.

  10. No use merging with the dead by Anonymous Coward · · Score: 0

    Unless you're into necrophilia.

  11. Hoping by Ol+Olsoc · · Score: 1
    I had to buy a Windows laptop in order to run some SDR software I had to work with. Then they released a nice version of the software in iOS. But my main platform is a Mac.

    I'm keeping my fingers crossed that I might be able to go Windows free again. Then I can give the laptop to someone I don't like.

    --
    The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
    1. Re:Hoping by bondsbw · · Score: 1

      2004 called to let you know that Macs can run Windows now.

      --
      All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
    2. Re:Hoping by Ol+Olsoc · · Score: 1

      2004 called to let you know that Macs can run Windows now.

      But its still Windows, with all the update fun that Microsoft provides.

      --
      The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
  12. iOS Andriod by Anonymous Coward · · Score: 0

    This is a fact and itâ(TM)s undisputed. Also, Trump supporters love gay sex. Why?

  13. Yes pls by Smiddi · · Score: 1

    The sooner Apple allow iO/S apps to run on Macs the better.

  14. Its a slow merge by Anonymous Coward · · Score: 0

    Apple will eventually merge IOS and Mac OS closer together if for no other reason then to make everything better at cross platform use. This is he whole ideal of progressive web apps is to eliminate having to make a app for different platforms. Apple's biggest problem though is that it tries very hard to keep everything within its own closed end ecosystem which seems to be going against what is happening elsewhere.