I expect a lot of franken apps not fitting into the system. As a developer, I would be happy to write a new interface for each platform. If only we had not bottom-raced software prices to levels that make it hard to create an app, let alone with custom interfaces for different platforms… So are we really solving the most important problem with Marzipan?
Marzipan doesn't seem all that useful for games, since they'd be targeting OpenGL or Metal for their UI anyways (plus I think a lot of games use Unity anyways, which does a lot of the hard work from what I hear).
Apple said during their subscription presentation that the games that are part of the subscription service will run on Macs, iPhones, iPads, and AppleTV’s.
Speculation is that it’s part of the Marzipan effort.
Marzipan means (I think?) you get a lot of the the basics: get a window, setup a gl/metal context, start drawing. That's more or less the entirety of a game's output.
Input then means adding a mouse/keyboard path in addition to touch events and it seems like that's something that should be easy :D
Honestly the effort to setup a GL (and I assume metal) view is kind of annoying on macOS.
> Marzipan means (I think?) you get a lot of the the basics: get a window, setup a gl/metal context, start drawing. That's more or less the entirety of a game's output.
There's a template in Xcode to set all of this up for Metal. It takes about five clicks.
For OpenGL, it's as simple as adding an NSOpenGLView to a nib.
But compare to just recompiling your IOS app to marzipan - you no longer need to have separate paths to initialize the gl context - all you need is the different event handlers. I like to imagine that a point+click name wouldn’t even need that.
You're really grossly overstating the effort to port a typical full-screen OpenGL/Metal application over from iOS to macOS or vice versa. It's literally a 1-hour job at most to get a drawing context initialized and up and running even when starting from scratch. Any experencied dev who has done it before just re-uses what's already there and will be done in 10 minutes tops.
Obviously you're not even 1% of the way of 'porting your iOS game to macOS' after that, the remaining 99% will be in re-implementing a mouse-based UI, and dealing with the fact that your running on hardware with completely different capabilities and performance profiles. Marzipan will not be able to help with any of that.
> That's more or less the entirety of a game's output.
Output is only a very small subset of a game. You need stuff like UI layout or Scene graph with transitions, tweening, texture atlases handling, animation, etc. A good game engine like Unity or libGDX provides all that without a game programmer having to reinvent the wheel.
See for example a list of classes the libGDX API provides:
Sorry, what I was trying to say is that basically all games want to do is get pixels to the screen - they're aren't really using the OS to do anything else: no system UI, etc
That's my point as well: you don't really need Marzipan for this. Putting pixels on the screen using OpenGL is already pretty easy for pretty much every platform.
Haha I’m not saying you need this, I suspect for many devs using marzipan and adding mouse+keyboard handlers is probably less work than setting up a real Mac app.
But for games I’m not super concerned as they’re not generally heavy on the OS UI.
Marzipan apps use fewer system resources, at least, and they tend to respond to platform conventions better (you know it's a low bar when I'm saying this about Marzipan :/)
We can always hope, but the Marzipan apps I have used so far (News and Stocks) are incredibly slow and don't adhere to platform conventions at all. I truly hope (and believe) that they are not representative of what Marzipan will be able to do in the future.
I have never used a single Electron app that was nearly as bad. In fact all Electron apps I have used are pretty good (VS Code, Spotify, Exodus). Yes they do use more memory, but not nearly enough to pose a problem for my 2012 Mac mini with 8GB RAM.
> but the Marzipan apps I have used so far (News and Stocks) are incredibly slow and don't adhere to platform conventions at all
I agree. We do not have much to judge off of yet, so I'm holding out hope these are not final examples. Apple knew people would find out what was being worked on so went ahead and gave a small early preview. What we see at this years WWDC will be telling.
That’s the entire point of the article. Even though you could take an iPad app and make it work on a Mac, you shouldn't. Just like you can take an iPhone app, and make it work on a 12.9 inch iPad with no changes, even though you should make interfaces changes that make it take advantage of the larger screen.
The concern isn't necessarily that the software is /bad/, it's that you get a bunch of iOS apps that just get recompiled to macOS with no thought to the different interface being used, etc.
The real head scratcher is that it's not really that big a deal to port your iOS app to the Mac, development-wise. You're probably using objective C or Swift already, so no need to switch language or libraries. If you've properly separated your ViewControllers from your business logic, then you can share a huge portion of your existing code base. If you have an iOS app, you're already between 50-75% of the way to having a great Mac app.
The most important problem to solve is envisioning the UI of your app in a world of mouse/keyboard input, arbitrarily resizable windows, context menus, and how to properly move from iOS UI conventions to Mac UI conventions. This is critical in order for the app to look like it belongs on the platform.
My beef with Marzipan is they're basically saying, "LOL don't bother with that," so yea, I agree the most likely scenario is my future Mac desktop full of Marzipan apps is going to look like a desktop full of little phone windows with neanderthal phone-oriented interfaces because developers can't be bothered to re-think their UI a little.
I agree for the most part but up until recently (2016?) I remember that the ViewController life-cycles were actually pretty different.
The problem with AppKit vs UIKit is that most of the things seem to be the same until they are not. At that point, you try to hack AppKit to behave like UIKit (probably cause you have some code already written for UIKit) which generally turns out to be a fools errand.
For example, I hate the usage of the Flyweight pattern in AppKit. UIKit doesn't suffer from this.
>If only we had not bottom-raced software prices to levels that make it hard to create an app
Are there any product or services sold in an open market where its price is not bottom raced? Even Apple products are many times cheaper than they were in the 90s.
Apple products might be cheaper compared to 90s but they still incorporate a significant margin. An $800 iPhone can end up having a margin of about $300-400. Even if you incorporate other stuff R&D, marketing etc, you still have $200+ margin on the phone.
Compared to that, consumer software has become priced around 5-10 USD. At $5 and 1000 customers, you get $5k in revenue. After Apple/Google's commission, you get $3500. Factor in other stuff for marketing, customer support etc. you barely are left with profit. At 200 hours of work, that is $17.5 per hour. And getting to even the first 1000 users can take a long long time. Another option is to make it free, supported by ads, but then you have to have a much bigger user base or you'll be making pennies. On top of that, people get angry when you charge for upgrade or subscriptions. Checkout twitter threads for Reeder 4 and Tweetbot 4. Plenty of people complained - "why do we have to pay again"
Consumer software is currently a terrible space profit/revenue wise. B2B is a much better space to operate in.
I'm currently building a pocket/instapaper alternative but all my investigation around revenue/pricing/profitability left me with much less optimism than I expected. I'll complete this project but I'm probably not going to get into B2C again.
So Apple is trying what Microsoft did years ago: Platform convergence.
It's quite ironic because as far as I remember, Apple used to have a strong stance against that, showing e.g. by the fact that Macbooks never come with touch screens.
Also, there was a loud opposition at least by power users who didn't like that change (sometimes just for the sake of hating change or hating MS IMO). Let's see if it will be different in this case.
I don't know how Marzipan will turn out, but Microsoft has a history of trying good ideas way before they are viable and make the whole concept look unhealthy.
For instance PDAs and 'smartphones' where tried and got mild commercial viability way ahead of time with Windows Pocket, but they couldn't push it to the point it could be mainstream. Tablets were also tried first. Netbooks. Motion tracking in games. ARM base laptops (we're not there yet, but that should be coming ?)
I almost prefer Google's attitude of just launching and roughlessly killing new products, the stigma left is smaller.
> Microsoft has a history of trying good ideas way before they are viable and make the whole concept look unhealthy.
I think it also had to do with their sheer size. Researching stuff is fine, but in many cases they were pushing out half-baked solution with the force of the herd of elephants that Microsoft is. Had a company 1/100th their size tried the same thing, no big deal, just ignore it.
But when a company worth $1tn these days does the same thing, whatever they're promoting is seen everywhere.
They really needed something in-between Microsoft Research (research almost nobody sees) and full blown Microsoft. Maybe a Microsoft Skunkworks Startup? :)
Zune and zune subscription music were not half baked though. I used it for years. It was simply ahead of its time. Even jobs said subscription music would never be a thing because ppl want to own their music.
It was definitely ahead of its time, because people forget about what makes Spotify/Apple Music/Google Play so much better than purchased music: Persistent Internet Connection.
The iPod, Zune, and Creative Nomad existed for something like 7 or more years before smartphones came around.
It's great that you could subscribe to a music service and sync with whatever songs you wanted, but that doesn't seem terribly useful compared to purchasing albums if you have no ability to queue up any song on demand.
Spotify feels more like unlimited access than those subscription services ever did.
As for Jobs' opinion, I think he mostly just held very personal feelings toward albums as a dude who grew up in the classic rock era. Plus, at the time, subscription services existed and just weren't very popular (see above).
Microsoft (+ Intel) murdered the netbook in one of the most insane self sabotaging plays I have ever seen.
Combine that with the launch of the ipad and the future of ARM based laptops was delayed over a decade. Netbook makers were poised to release Arm netbooks only to get scared when the ipad was announced.
It wasn't self-sabotaging. The first netbooks ran Linux and ran okay, at a time when Microsoft was about to EOL Windows XP and Vista absolutely wouldn't run on such devices. If they'd caught on, it could have spelled the end of Microsoft desktop hegemony. It prompted a panicked reaction of extending the service life of XP, while introducing restrictive licensing to pitiful 1024x600 displays (which fit the current crop, but restricted their growth). It was a classic "embrace/extinguish" response to an existential threat.
I don't know what makes people react the way they do so that MS ahead-of-time releases "make the whole concept look unhealthy".
PDAs and 'smartphones' didn't become mainstream pre-Apple, but their design was also more productive. Were it to catch on, we'd have better tools. Microsoft still makes superior tablets, and the only OS for tablets that's usable for productive work.
I only wish they didn't rush to market with Windows phones. Their UI language was a breath of fresh air, and they had a chance to make good smartphones for pro users and professionals. People usually blame the app store, but based on my brother's experience with an early Windows Phone, IMO they released the OS with way too little built-in features compared to contemporary Android systems. It could have survived longer were it more functional out of the box.
PDAs like the Palm Pilot (and to a lesser degree Windows CE devices like the iPAQ) were quite mainstream in the late 1990s/early 2000s. Not only did I and my friends have one (in fact I went through several) but even my elderly mother did (although she mostly played solitaire on hers).
My 500 euro Symbian smartphones were quite ok, and by the time the unfortunate "Burning Platform" memo arrived, it was quite good and Symbian C++ was finally on its way out, we had Qt, Java, Python and Web Widgets to play with as platform languages.
> PDAs and 'smartphones' didn't become mainstream pre-Apple, but their design was also more productive. Were it to catch on, we'd have better tools.
I know a sizeable number of people were extremely productive on their PDAs. Yet I think there was heavy downsides that were only overcome by sheer dedication from super users:
- laughable battery time, difficult to extend compared to other portable devices
- cell connectivity was just not a thing, or it would half the already thin battery time (tried with a compact flash modem)
- carrier support was super limited where I was, I had to get a new contract from a geeky carrier just for the device.
- downloading and running software from the device itself was possible yet there was very few stuff that could be downloaded, making the device mostly a side companion to a computer
I used a Toshiba PDA on and off for a year, tried a Compaq one as there seem to be more enthusiast on it, it still felt like it wasn't going anywhere with really little to no engagement from Microsoft from a standard user perspective.
Disclaimer: it was in Japan, but comparing PDAs to feature phones, phones had:
- a workable camera very early on
- a decent ecosystem of Java apps downloadable from the phone without any computer reliance (and they were fairly easy to code)
- decent battery life, easy to extend
- fast and efficient mailers (though lack of attachment support and alternative accounts was a pain)
- very good connectivity, of course
- decent calendar/reminder/contacts features (not auto synced though, which was a PITA)
Genuinely, in a lot of aspects, feature phones were more 'professional' and productive than PDAs for anyone in the go or heavily relying on a mobile device. Just like the iPhone is now, really.
The windows CE phones were a step in the right direction, but they still didn't get major carrier buyin, and battery life was still way lower than their generation's feature phone who were starting to get GPS, MP3 players, payment apps etc.
Note that while the downsides you mention were naturally overcome by smartphones today, they're a) kind of expected to be improved on by progress of technology, and b) are completely orthogonal to the features of the PDAs which were not replicated in smartphones of today. Like, physical keyboards, stylus access, productivity-oriented OS.
Pieces of a perfect productivity tool are, or were, all there, scattered across time and devices. PDAs, feature phones, modern smartphones. For some reason, they were not put in a single package so far.
You are right that a lot of features weren't brought to current smartphones, just as current OS are not 'productivity' focused the same way windows is for instance.
I personally think it's because they just weren't worth it for the general public (including pros). Keyboards on android devices didn't convince, interestingly stylus and heavy multitasking are kicking and alive on the Samsung Note series, but only on the iPad for iOS.
'PDA's for specific, dedicated use cases are still a ton in the wild, just as custom android devices also flourish in the manufacture, retail or goods management world (basically "true" productivity-oriented worlds). They found their niche in that respect, the same way Google Glass also went to the business world in face of customer resistance. I see it as a natural evolution in that respect.
Tablets they were definitely ahead of the game on, though the hardware wasn't ready to be affordable the OS has never done well in that environment so it didn't work out.
I'm not so sure about netbooks though: I remember that being something the played "catchup or kill" on. Any links to refresh my history?
You're right about Netbooks. Microsoft were late to the game on that one. All the early ones were Linux - and still hugely popular too. Microsoft then had to heavily "subsidise" XP to even compete (there's a lot more to it than that but that was the essence of it).
Interestingly Apple said they had no interest in the Netbook market. They released the MacBook Air which had a roughly equivolent form factor but at a wildly different price point.
Not just that: they effectively had to extend its life as there was no way Vista was going to run well on those small devices and 7 wasn't ready for roll-out.
>So Apple is trying what Microsoft did years ago: Platform convergence.
Mostly API convergence. Which they have been doing for years now (adding UIKit parity to OS X), Marzipan is just the latest and more encompassing version.
>It's quite ironic because as far as I remember, Apple used to have a strong stance against that, showing e.g. by the fact that Macbooks never come with touch screens.
And they still consider those two as different use cases, better served with different UIs.
Marzipan is not about sharing the UI paradigms -- its about making it easier to port common code.
The mistake Microsoft made was to stubbornly tie user interface convergence to their platform convergence effort. Everything had to be Windows so everything got start buttons and all kinds of cruft that wasn't needed and lead to bad experience.
Making platforms more similar so it easier to target that platform is very nice for developers. If you can do it without losing what makes users want the different devices then there's no downside.
It is similar, but it’s also different. I still think Apple wants to avoid mixed mouse and touch interfaces and also wants to avoid switching on the fly between those two interactions models on the same device. Their goal will be to give developers the tools to use a shared codebase, but still being able to provide the right accommodations for mouse input on the Mac. I don’t think touchscreen Macs are planned.
How well they can pull that off is a different question altogether.
Mac users feel neglected anyway, so I’m very willing to let them try.
App convergence over different operating systems seems to bigger trend than platform convergence within an ecosystem, and Marzipan seems be Apple's response to that. I would much rather run a version of Slack's iPhone app than the electron version I'm stuck with at the moment.
The toolkit is not meant to just let you port the app directly from iPad to Mac even though you can. Just like you can just press a button and have an “iPad app”, you should make affordances for the Mac just like you do when moving an app from the iPhone to the iPad. That’s the entire point of the article.
To get an idea, the developer has been playing with a tool he wrote that lets him take an x86 build of an iOS app - when you run any iOS app in the simulator it creates an x86 build - and “marzanipies” it.
For instance he took a binary build of Marco’s Overcast app (with permission) and turned it into a Mac app.
If Marzipan gives me an easy way to debug my iOS Metal apps on macOS (which isn't possible with the simulator), then it's already "good enough" for me.
I wouldn't read too much else into the project otherwise. Running iOS apps on a Mac may be useful for apps that are not much more than a glorified webpage (so... hmm, most apps?), but it won't be the way to "unify" the mobile and desktop worlds (which still doesn't make sense anyway).
There really exists no good reason that you would want to have the same UI across all of those platforms, for anything beyond the toy examples that the Windows Store has been plagued with. The display and input device constraints are nearly disjoint, unless you go to an incredibly basic common denominator.
I've always been a Windows dev, and I've never seen a compelling reason to take up UWP.
I disagree. I think UWP has done a really good job technically behind the scenes, but poorly explained publicly of showing how one device's display and input device constraints are another device's accessibility/ease of use guidelines. That the basic "common denominator" made things easier/better to use in general for everyone, even if users/devices were capable of fewer constraints and more guideline breaking.
In addition, UWP and Fluent Design System had a hard time coming back from "these are the constraints in all situations" to "here's how you flex when these are the constraints of the current system versus when they are merely guidelines that you can break if your user accepts it". That became a focus in Fluent Design System 2.0, but it certainly does feel like it may have been too late avoid the "worst common denominator" branding that Fluent and UWP got painted with early on.
UWP/Fluent did a lot of things right technically that Apple should apply to efforts like Marzipan, they just might not realize it based on the tarnished brand.
Necessary no. Hurtful? I don't think so, if I may say so myself.
It's a comment to put into perspective the relative insignificance of the platform -- and thus that the statement of the parent that it supported that too doesn't amount to much.
It also shows how MS effort was either badly thought out from the start, or at least failed -- and all those cross-platform touch-first changes of Windows UI where later toned down.
Sure it is. We must never forget that one of Microsoft's biggest selling points for UWP, and by extension the Microsoft Store, was to port apps to a platform that was, frankly, dead on arrival, at a time when the vast majority of Windows users were using mouses and keyboards.
I don’t think convergence is their current goal. UIKit is simply a more “modern” API for writing GUI apps. AppKit hasn’t been evolving much in the past decade.
That’s just not true. AppKit has evolved a lot since 10.6. Big changes in Lion and lots of incremental improvement since.
UIKit may be more modern in some specific aspects, but it’s also far more limited. Here’s a good post highlighting some of the most obvious differences:
https://pilky.me/appreciating-appkit-part-1/
I’m really curious how Apple is going to solve the HIG problem.
Surely Apple won’t lower the bar for macOS apps, right? (I plead so... or why use a mac when WSL2 is out and Linux desktops are getting traction?)
My naive thought is that Apple’s Marzipan will add a layer to display UIKit components as AppKit components that follow the HIG; Currently all kind of differences are present like textbox radius, modal views(!), etc...
Maybe some UIKit components will be mapped to AppKit ones, and some others (that are only in UIKit) will also be added to AppKit?
> why use a mac when WSL2 is out and Linux desktops are getting traction?
This is applicable only for devs. Mac is not going anywhere for people in a lot of industries - writers, photographers, business, smb etc. WSL changes nothing for them and Linux was not in consideration anyways.
Even for devs, I can argue that Mac/Windows are preferable over Linux. Don't get me wrong, I love Linux but only on the server. Using Mac/Windows adds significant QoL improvements which are just not there on Linux.
> Even for devs, I can argue that Mac/Windows are preferable over Linux. Don't get me wrong, I love Linux but only on the server. Using Mac/Windows adds significant QoL improvements which are just not there on Linux.
Please, not this same old tired argument. I could say the exact same thing but in reverse, it would still be true for some definition of truth and we'd be none the wiser.
If you're absolutely bent on talking about this tired old topic, concrete points are what you should be aiming for instead of vague value judgements.
Maybe you could say that, personally, but quite a lot of developers don’t. I follow a lot of high-profile researchers at places like Nvidia, and they often discuss the desire to replace their Mac for dev purposes but have not found a quality alternative.
An optimistic hope is that the Windows subsystem for Linux will evolve and mature beautifully. But it’s not there yet, and even then you’re often stuck dealing with significantly inferior hardware. So Mac tends to be the standard that a significant portion of the world’s developers compare against.
> I follow a lot of high-profile researchers at places like Nvidia, and they often discuss the desire to replace their Mac for dev purposes but have not found a quality alternative.
How ironic: Linux would be a lot more well-positioned for desktop use if Nvidia would open-source its proprietary drivers.
Frankly, though, I find Linux eminently usable and preferable to macOS or Windows.
That's absolutely fine and good for you, but the plain fact is for the vast majority of people, including most developers, that's not the case.
Having a single consistent desktop with a ton of financial resources behind it, and a commercial desktop software market also built using huge financial resources, makes a big difference. Financing is also why Linux kills it on the server. Redhat, IBM and many more have sunk $billion(s) into Linux as a server OS and it shows, but that level of investment has never happened for the Linux desktop.
I think the closest equivalent is Canonical. Canonical spent a lot of money on Desktop Linux, and to be honest, you can see the impact. Desktop Linux today is far more usable than it ever was, and the millions spent by Canonical are a large part of that.
Unfortunately, Canonical appears to have scaled back their desktop spending, so it remains to be seen if someone else will step in. Maybe the System76 or Purism folks, or maybe Canonical will focus on Ubuntu desktop again, especially with Shuttleworth’s recent comments that he has been surprised with the number of large organizations requesrion Linux laptops, esp for their data science teams, etc.
> Mac is not going anywhere for people in a lot of industries
~18 million Macs were sold last year, surely not all of them to developers. Mac sales declined slightly compared to previous year, but market share increased as also fewer PCs were sold.
Yeah, this is applicable only to devs, but well, there’s one less reason to buy a Mac :-(
If this repeats, well, one day Windows might be, well, not great, but ‘good enough’ for everyone, and the PC UX story won’t improve... :-(
I also really hope that the non-integer scaling was a very temporary hack of a solution and not how things will be going forward.
For those not familiar, iOS generally sizes UI elements at a larger number of points than macOS to account for reduced accuracy of touch vs a mouse pointer. The solution in the existing Marzipan apps is to simply scale the output down by about a third so things seem more “Mac sized”. It’s very obvious in text-heavy apps like News, and looks awful.
As a person who has been a fan of the Apple ecosystem, it’s sad to hear that the route Apple is taking to increase the number of Mac Apps is, well, basically lowering the bar :-(
Preferably Apple can open the private framework that the new MAS uses or one that the Photos app uses (actually Photos have similar problems; like drag&drop not working) but it is much better than Marzipan, which is similar to the situation of Electron :-(
I'd follow him for the technical discussion, not for his analysis of where Apple is taking this. He seems to take a quite extreme view on macOS basically being old and busted and it being time to throw it out, and I feel he either ignores or misrepresents arguments that don't quite agree with him. As one example, he has a post where he makes a "Good Mac Citizen" except it's really not one at all: https://www.highcaffeinecontent.com/blog/20190302-Making-Mar.... I think someone must have mentioned this to him, because he recently felt the need to talk about his years of experience with macOS and how he's great at making good Mac apps…
He basically made the Marzipan apps we have today. They are at best passable apps, but hoisting a couple of buttons into the title bar and using the same bland "large sidebar tableview" style does not make an app into a good Mac app. Apple has not yet provided the APIs to make these apps good Mac apps. Calling these apps "good" is quite a stretch.
(Before someone mentions it: yes, I know he has improved his apps since his blog post, but it's mostly just been in response to people saying that he's missing something that AppKit provides for free, and he will go in and monkey patch the thing in hackish way and call it a day. I have a feeling that he actually personally thinks that these are good apps and is annoyed that people are calling him out for believing this.)
>I have a feeling that he actually personally thinks that these are good apps and is annoyed that people are calling him out for believing this.
It's more like he worked hard on Twitter to become "the Marzipan guy", so now he has stake in this game. If he were to express the slightest concern, his consulting/Patreon revenue would suffer, so he has to believe™ in Marzipan.
I think that is all we are going to get from this, hastily ported small apps where the fact you even have the app on your Mac outweighs the bad UI. I don’t think it is useful to port large apps because the iOS kit just doesn’t support everything you need for a good large Mac app.
That's precisely what Marzipan proposes: additional APIs that allow iOS apps to be good Mac apps without needing to port to AppKit. Looking at how it behaves now, it seems to either bridge some UIKit concepts to AppKit directly or replicate AppKit functionality within this macOS-specific version of UIKit.
Try reading this: https://bzamayo.com/marzipan
Basically, unless Apple makes Marzipan to map UIKit components to AppKit components, Marzipan really can’t make a ‘Good citizen Mac App’.
Keep hearing people talk about how this technology is about porting iPad apps to the Mac, personally I don't see that as why they're doing this at all.
Today the Mac has a very healthy ecosystem of professional apps, however the same can't be said for the Pro iPad range, which despite a handful of admittedly very good outliers (Procreate, etc) it's very lacking in apps for all professional workflows.
I don't see Marzipan existing to bring those few iPad apps to the Mac, it exists to remove the excuses for Mac developers to only build for OS X.
Except Marzipan is about UIKit on the Mac so it will definitely be easier to port an iPad app to the Mac that it would be to port a Mac Appkit app to the iPad.
That said, a developer now has fewer hurdles in developing an iOS version of their app because if they rewrite it in Marzipan, they can continue to develop their macOS and iOS apps in parallel, and they can just drop support for the pre-Marzipan macOS version of the app.
> simple and familiar on the Mac, like the pop-up button, might be implemented for both iOS and macOS. That simple control doesn’t have any analog on iOS
The Home app is using UIPickerView on Mac when it should really be using NSPopUpButton. Likewise, Mac apps using NSPopUpButton should use UIPickerView on iOS. At least, that's my view of things.
The whole point of any merge is that one entire UI framework goes away. There is no way Apple will keep two entire APIs available after a transition period.
It looks to me like iOS will win, this has been obvious for some time based on the revenue and new API work:
iOS may "win" in the sense that UIKit on the Mac gets the blessing of being the preferred way to develop apps, but I would eat my hat if Apple decided that UIPickerView's stupid spinny wheel was the "new" way of doing list selection on macOS. I think it is significantly more likely that UIPickerView ends up being "themed" on macOS to look like NSPopUpButton.
Sure, they'll present some controls differently, and some controls for Mac OS will need to be added (for menus for example). I'd expect them to attempt to keep differences in presentation to a minimum though.
yes. Or even better, there should be a new abstract control with a semantic "chose one in a list" meaning that renders as an UIPickerView on iOS and an NSPopUpButton on the mac.
This article is aimed at macOS developers, who generally have a decent idea of what Apple is working on. I have a comment downthread which has a short explanation of it for those who don't follow this closely, since someone else has a similar complaint: https://news.ycombinator.com/item?id=19875612
I originally learned Objective-C and Cocoa in 2001, and released my first Mac OS X app in 2003. When the iPhone OS SDK came out in 2008, it had been a while since I had written software for an Apple device.
Nowadays, I probably spend between 10-40 hours each week writing Obj-C and Swift against UIKit, but never the long-in-tooth AppKit.
I’m excited to get back to building Mac apps, and porting OneBusAway to the Mac this summer. It’ll be nice to not have to pull my phone out of my pocket or launch a simulator to be able to tell my wife about when she needs to leave for the bus.
There will be a lot of garbage apps, but this is no different from what already exists on iOS. And when was the last time you looked at the Mac App Store anyway? I only ever use it to install Xcode updates.
MS and Google are committing big time to supporting developers with excellent support for all things linux in ChromeOS and Windows. This is an area where Apple used to be strong (through shipping a BSD OS with decent inherent compatibility) but has made life harder in recent years by basically neglecting that side of their product portfolio.
The lack of servicability of mac book pros and the many hardware issues with screens, keyboards, etc. paired with a less than stellar hw. performance means that it just no longer is what it used to be: a best in class hardware platform with a no nonsense OS that just works. The hardware is increasingly meh, and the OS feels stale and limiting. Actually, it's been a while since Apple launched a product that I really wanted rather than grudgingly upgraded to (like my current MBP).
IMHO Apple is increasingly fighting itself into a corner by insisting on exclusivity to their hardware platforms through walled garden style software platforms. Inevitably some developers and users are ending up on the wrong side of that wall. E.g. Metal vs. Vulkan, Chromium vs Safari, Swift/objectiveC vs. just about anything else. It's all so pointless. They do the same things, more or less, without doing something better in a clear way. They're basically just obstacles for users and developers, not key enablers.
MS just threw in the towel with Edge and is together with Google creating an ecosystem outside of Apple where a lot of interesting things are happening in the next few years. I'm no longer sure a mac is the best platform to experience that. IMHO this is the biggest challenge against Apple's dominance in two decades. MS is back and moving very aggressively.
Apple is locking themselves out of important markets through their choices in software platforms. E.g. the gaming market (aside from casual stuff for IOS) is a multi billion dollar market where Apple is an after thought. I have some games on my mac but most of the big titles don't ship for mac. The mac platform is just too different for them to bother and when things like opengl get deprecated, things don't get any easier.
This is a failure on Apple's part to accommodate developmers and anticipate where the market is going. On paper, Apple is an ideal platform for games: homogeneous hardware platform and a user base that is spending liberally in the Apple store. Why would you not want to target that as a game developer. Apple ought to be making billions from this and they just aren't. This "our way or the highway" attitude is locking them out. VR is a great example of something that is happening almost completely outside the Apple platform. Countless wealthy people spending way too much money on games, PC hardware and VR goggles and Apple gave us Metal, broken Nvidia drivers, and tumbleweeds when it comes to any kind of meaniningful VR/AR on Apple hardware.
Apple needs a new strategy. Marzipan is not it. It does not appeal to developers outside their bubble and that's where the action is these days. They need a new strategy that reverses the trend of developers working around them. More of the same is not going to make that happen.
Hint, except for the Switch, which has anyway NVN as their main API, no games console has had any big love for OpenGL or Vulkan, and it has never bothered AAA studios.
Apple follows what was standard practices across the 8 and 16 bit industry computer platforms, the PC was the outlier thanks to Compaq's clean room reverse engineering and IBM's failure to retake the PC back home with the PS architecture.
If anything, the current smartphone, tablet and 2-1 convertibles show that regular consumers prefer that model, not plugging PC Legos.
The desktop gaming market is minuscule compared to mobile. There was just an article on HN yesterday saying that most money in games are spent on mobile.
And that's in a market that is basically ignoring Apple users and their money. And you are forgetting that people need hardware to run those games as well. Apple sells expensive hardware but not to gamers .... who spend many billions on getting the best FPS. Apple is doing very little to tap into any of that. It would drive hardware sales and if they play their cards right also app store sales. Particularly VR is causing people to spend thousands of dollars on non Apple hardware.
You are right that mobile is currently bigger and Apple probably makes quite a bit out of IOS related sales of that market. But Desktop gaming is not nothing. Even for Apple.
I've read two pages of the article and I've still no idea what it's talking about. They're clearly going for the "shrouded in mystery" marketing approach, but I haven't got time for that.
Can the title be updated to describe what this is actually about rather than just having the name of an almond-based confectionery item?
Marzipan is an internal framework for running apps written for iPhone on macOS, set to be publicly released to developers this June at WWDC. Since the UI paradigms for the platform differ, it's an open question what will happen in these cases and whether the resultant apps will be of high quality. Many developers predict this as being an opportunity for Apple to adopt a new UI paradigm for macOS apps that matches that of iOS more closely.
I have no idea why you are being downvoted. I submitted the article and even I admit in hindsight that neither the title nor the article is clear to someone who isn’t steeped in the Apple ecosystem.
Same. I know that "naming is hard" but it seems like these days software people take a perverse delight in giving things completely unrelated names. At least back in the day we used impenetrable acronyms which kind of made sense when explained.
Apple has a precedent. The Carbon API was so named because "all lifeforms will be based on it". The Cocoa API was so named as an alternative to the Java API, at one point a major pillar for Mac OS X before Apple discovered people preferred to learn Carbon/Cocoa than bother with Java.
Marzipan, if the name does stick, could be "the icing on the cake" that brings iOS developers to the Mac. It seems as though Apple has been spending the past twenty or so years preparing a small bakery.
We patiently await for an updated version of discoveryd to be reintroduced into macOS, codename Tea-and-Biscuits.
Marzipan is not something that is public facing. It is an API for software developers. It will get a name at WWDC in a few weeks and then it will have about as much public awareness at UIKit.
Agreed. I understand unexpected brands for consumer facing products – Apple and Blackberry come to mind. But for a tool / library meant for developers, it seems a bit over the top.
Marzipan is, by definition, mostly made from almonds. I'm sure knock-off marzipan-flavoured confections exist, but that doesn't change the meaning of the word.
I have little hope for Marzipan. Apple’s own Marzipan apps are meh at best.
And then on iOS... iOS’ own dashboard no longer works in landscape mode. Apple’s own Books app’s interface only has portrait mode. And this from a company which expects other devs to be able to create universal apps that target different screens and interaction modes.
