Resolved Applications for Mac OS X, without Apple's operating system

[grahamperrin]

Seeing today's brief video about work in progress on CrossOver Android, then finding last year's blog post, makes me wonder …

… whether some future product, from any group of developers, will allow easy use of some apps for Mac OS X – without Apple's operating system. Some, not all – for starters, I guess that it'll be impossible to run apps that were delivered through Apple's App Store. Some apps will be too closely tied to Apple private frameworks, and so on … but maybe some apps have the potential to run, in the future, without Apple's OS.

I expect (and understand) that for as long as there will be Mac hardware, there will be a majority of users preferring Apple's OS on that hardware. If you foresee yourself having that mindset then (with respect) you need not reply to this topic.

If you like the idea of running an .app for Mac OS X without Mac OS X, please share your thoughts. Thanks!

(I'm vaguely aware of QEMU, for example Running Mac OS X as a QEMU/KVM Guest (highlights), but it's not of immediate interest to me.)

 

[maflynn]

whether some future product, from any group of developers, will allow easy use of some apps for Mac OS X – without Apple's operating system

Why?

Macs have s tiny fraction of the computer marketshare, so the demand for OS X apps are not that high.
There are more applications for Windows, then OS X, so the likelihood of there being an app on OS X and not windows is low. While there are specific apps that are OS X only (take blocs app) there are plenty of alternatives.
Wine used for comparison has a high volume of apps that simply don't work, or work very well.
Many people just use the Mac App Store, so getting apps will be difficult, since the MAS built into OS X, there's no way to run that without OS X.

From a technical aspect, WINE translates win API calls and in a general sense, it's not 100%, there are more apps that don't run that do it seems. I'd have to say given how Apple locks down their OS even further then windows does, it probably makes it less likely to work.

To summarize, there's less demand, less supply of unique apps, higher technical investment to make it work. I see no positive end, the prospect of getting sued by Apple is high, and I'd say there's little to no prospect to make money.

 

[grahamperrin]

… App Store… getting apps will be difficult …

It will be easy to copy an app but (above) I guess that it'll be impossible to run.

… the prospect of getting sued by Apple is high,

I doubt that. Consider areas such as PowerPC - QEMU, OSx86, Pike's Universum – Great people share their wisdom without asking for anything in return… – how often has Apple successfully sued, or attempted to sue, in a relatively niche area?

Four years ago http://web.archive.org/web/20120422...to-icloud-calendars-with-third-party-software mentioned a prohibition but if I recall correctly, that related to unacceptable use of an Apple service and https://twitter.com/muhlba91/status/739422630009266176 offers a concise explanation.

and I'd say there's little to no prospect to make money.

I don't imagine it being primarily commercial. Recall, for example, the relationship between CodeWeavers and Wine.

More broadly, some developers choose to share parts of their work without asking for anything in return

 

[Tech198]

kind of reminds me of something from CrossOver

 

[Jessica Lares]

There's not only a "why", there's a "where do we start" question. When people come to Linux and the Mac, the biggest problem they have is that they can't run Microsoft Office. The next thing is probably the Adobe suite on the Linux side.

But there isn't that universally used app on the Mac. Maybe Safari and iTunes, but they're the most controversial Apple apps that most try and get away from.

 

[maflynn]

But there isn't that universally used app on the Mac. Maybe Safari and iTunes, but they're the most controversial Apple apps that most try and get away from

That's basically what I was getting at. There's really no demand for such apps, and for those that do want to run those, they'll either buy a mac, or build a hackintosh.

 

[grahamperrin]

… Maybe Safari and iTunes, but they're the most controversial …

A year or so ago I might have described (pre-Yosemite) Safari.app or open source WebKit.app, alone, as highly desirable. Then (Mavericks) Contacts.app … although I rarely use the multi-CardDAV-service features that make it desirable, so I'd probably use that in a virtual machine. Plus Finder.app because there's no comparable alternative with Miller columns … although since trying Upthere Home for Mac, a few hours ago, I'm more open to the possibility of working partly without a hierarchical file system; and there's work on a web client.

Why?

For Executor, first released in 1990, there were various frequently asked questions – if those FAQ included nothing about the rationale for existence of the project, it was probably because the home page kept it simple:

• for anyone who wants to run Macintosh programs on non-Macintoshes.

For me now it's similar. The simple wish to use a 'Mac app' on/alongside an alternative to OS X – without a frequent overhead of virtualisation of OS X in its entirety.

… "where do we start" …

To my surprise, I found that something began probably in 2012 (there's a screenshot of a terminal window showing Mac OS X 10.8 (Mountain Lion)): Darling.

Developers may find Darling interesting as a playground to work on something extraordinary. There is a lot of work ahead of us, but not so much to have usable results.​

 

[grahamperrin]

Finding Darling (via Ask Ubuntu) was enough for me to mark this topic as resolved.

Around the same time I found a reminder of something from around ten years ago, The Cocotron:

• Cocotron: Cocoa for Windows?
• Mac Daddy World » Blog Archive » Adventures in Cocotron
• Cocotron for Cross Platform Apps Developed on a Mac | MacResearch

A few closing notes:

• application binary interface (ABI)
• Linux® emulation in FreeBSD
• FreeBSD Handbook Chapter 10. Linux® Binary Compatibility – not really emulation, it is an ABI implementation
  
• Linux Direct Rendering Manager (DRM)
• Use linuxkpi in DRM - FreeBSD Wiki (highlights)

 

[997440]

To my surprise, I found that something began probably in 2012 (there's a screenshot of a terminal window showing Mac OS X 10.8 (Mountain Lion)): Darling.

Developers may find Darling interesting as a playground to work on something extraordinary. There is a lot of work ahead of us, but not so much to have usable results.

Although you've marked this as resolved, I thought there might be interest in the new developments with Darling.

[...]
This is why Darling now has a branch named using-machos-experiment where all of Darling's components, with the exception of a few small executables required to bootstrap Darling, are built as Mach-O files. Thanks to the Clang compiler, this isn't as hard or daunting as it may seem. Most Linux distributions provide Clang with multitargeting capabilities, meaning it can natively produce Mach-O object files, as if built on macOS itself. The only missing piece was the linker, which was very easy to add and build during Darling's build process.

What it Means
This change will bring Darling even closer to a real macOS-like environment. There will now be real .dylib files in /usr/lib when running macOS applications. Applications doing all kinds of exotic non-portable operations (such as loading a standard system .dylib file into memory and then asking the dynamic linker to use it) will find themselves at home. In this development branch, all components are built as fat Mach-O files containing both the x86_64 and i386 versions, meaning the build is done in one go.
[...]

http://blog.darlinghq.org/2017/02/the-mach-o-transition-darling-in-past-5.html