Hacker News new | ask | show | jobs
by Lorin 1706 days ago
I just want a cheap way to live debug sites in Safari / Safari Mobile without being forced to purchase Apple hardware.

Only reasonable option I've come across so far is buying used hardware. VM under Win10/AMD seems like a PITA.

7 comments

Remember that running OS X (including in a VM) on anything other than Apple hardware is technically a violation of Apple's terms of service.

If you're just doing it for personal use, this probably isn't a big deal. If you're doing it for your business, make sure you consider the risks.

You can rent from Amazon for $1/hour

It supports remote desktop and everything you would need

You can rent from Amazon for $25.99 a day and then for $1.083 an hour after your one day minumum.

> Billing for EC2 Mac instances is per second with a 24-hour minimum allocation period to comply with the Apple macOS Software License Agreement.

Maybe say you have to pay for at least 1 whole day every time.
Sort of as there is a minimum of 24-hours.

> Billing for EC2 Mac instances is per second with a 24-hour minimum allocation period to comply with the Apple macOS Software License Agreement.

Do those 24 hours need to be continuous?
Yes. It’s in the MacOS ToS.
But... why?
So you get the full Apple MacOSX experience.
Does browserstack not work for you?
I have a macOS VM under VMWare running on Windows. It wasn't that difficult, found some guides online by googling obvious search words. The only thing I haven't gotten to work yet is the App Store, but I saw a guide for that, just haven't done it yet. You won't get graphics acceleration btw, but CPU performance is fine.

I believe the trickiest bit was running a macOS serial generation app and copying that value into the VM settings.

(I've purchased plenty of Macs over the years so pls Apple, this is just for dev purposes!)

Enjoy it while it last, in 3 or 4 years Apple will drop Intel macOS support.
By then, Windows 11+ will have moved onto ARM and whatever cross binary solution Microsoft is working on should be complete. Also, with emulation/virtualization, it's still perfectly feasible
I don't want to destroy your hope but take a look at ARM support in linux. (TL;DR the ARM space is very fragmented so taking a running system from one machine with ARM to another is not possible).
Fortunately, Linux lets you install things by compiling them locally instead of just auto-downloading a binary.

Are you saying that "aarch64" binaries don't run on all ARM chips?

3 or 4 years. sure not, they still sell intel macs on the website.
Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux

https://news.ycombinator.com/item?id=28797129

404 points by nixcraft 11 days ago | 117 comments

Used totally makes sense. I picked up a Mac Mini with a 27" monitor for $500.
It's a shame that web developers have to spend $500 to buy a bespoke web-browsing machine just to make their sites work better with Apple hardware. If Apple wanted people to treat their browser seriously, they should have simulators and developer tooling to spare.
or just release safari cross-platform.
Safari (not WebKit specifically; the rest of the browser) relies on OS libraries. Those libraries would have to be reimplemented for other OSes.

I don't mean that that would be an impediment to porting; Apple have done this before—Safari 5 was available for Windows. (And interestingly, vice-versa, IE5 was available for macOS!)

What I mean is that the differences in implementation of these OS libraries would mean that this version of Safari wouldn't be bug-for-bug compatible with macOS Safari; and therefore, testing on this version of Safari wouldn't necessarily get you what you want, if your goal is finding and squashing 100% of the bugs that testing on macOS Safari would allow you to find and squash.

To use a pretty close analogy, it would be like a development workflow for Windows executable that involved running them under Wine in Linux, and never actually under Windows. You've QAed for the API surface, sure; but you haven't actually QAed the software for how Microsoft's own library implementations work (and the bugs that those implementations introduce.)

You're not wrong, but in practice I'd imagine >99% of bugs are in the rendering / webkit layer, not in the OS integration layer.

Sure, if you're making a plugin that plays with bookmarks or 'Read Later', you'd likely run afoul of the issues you mention. But most web devs are concerned just about browser compatibility of rendering their web-app. In this context, as long as web page rendering and JS engine is identical between OS' it's fine.

This very much depends on the bugs. In the past I've found many bugs in text rendering (especially related to non-English text[1][2]), layering (inconstent opacity), audio and video playback, etc. which were dependent on the combination of browser, operating system, and, in some cases, hardware. The general trend has been for browsers like Chrome and Firefox to take over more responsibility but that's not what Apple has done in Safari so it looks like a lot more work to say they should duplicate OS functionality to make it easier for Windows-only web developers to test with Safari.

1. https://chris.improbable.org/experiments/browser/combining-h...

2. https://chris.improbable.org/experiments/browser/javanese-te...

Rendering issues are OS issues too. For example, Safari's font rendering depends on the particulars of macOS/iOS's font-rendering framework. Safari on Windows would presumably use Windows' font-rendering framework, with drastically different results, due to the different frameworks supporting different subsets of e.g. ligature-pair width hinting or hyphenation, thereby causing text to wrap in different places, such that the layout at a given font size + viewport size on Windows wouldn't be predictive of the layout at the same font size + viewport size on macOS. (Which is not even to mention the fonts you'd have by default on Windows and not by default on macOS, that would interfere with the font family cascade, and yet couldn't be suppressed from the cascade because some macOS systems do have them.)

Or, for that matter, there could be certain exposed -webkit CSS selectors that are really just features of some or another macOS rendering-layer framework, with no Windows equivalent — the same way that IE's ancient CSS "filters" were really just exposed DirectX features (e.g. filter: progid:DXImageTransform.Microsoft.blur). For these cases, testing on "Safari on Windows" would essentially just get you what testing in Chrome on Windows already gets you (unless Apple created an entire software renderer that brings in all of macOS's Quartz and all its subsidiary libraries as a big ol' polyfill.)

The point at which Safari is guaranteed to work like it does on macOS, is the point at which you're bringing in a polyfill consisting of 99% of macOS's frameworks. May as well bring in the last 1% as well, and call it a VM. (Ideally a thin-as-possible paravirtualized VM where the display driver is written to directly make DirectX calls, etc. — but VM client software is already pretty good at providing these sorts of drivers.)

I don't know about the early versions, but I believe the final version of IE for Mac, though also numbered 5, used an entirely different browser engine from that on Windows. Tasman

http://jimmy.grew.al/macie5-twentieth-anniversary/

Last I checked, there is a Windows WebKit/Safari build. I don't think it worked very well though: https://news.ycombinator.com/item?id=20700914#20701334

Edit: Looks like the new URL is https://build.webkit.org/#/builders/67?numbuilds=400 but the build has been broken for almost 2 weeks. The last successful build is the 300MB https://s3-us-west-2.amazonaws.com/archives.webkit.org/win-x... (as explained in the link above, the Apple Application Support libraries are required).

The M1 Mac Mini recently was only $600 on sale.
You can also find a refurbished M1 Mac Mini for under $600 on Apple's refurbished store.
Why not Browserstack?
Debugging iOS-Safari issues on a web page requires:

1) Access to a Desktop Mac and a Desktop Safari.

2) An iOS device.

The Safari debugger recognizes a plugged-in iOS device and then allows to debug the iOS safari remotely. That's the only reliable way to find iOS specific JS or CSS issues. Browserstack alone does not help, unfortunately AFAIR.

You actually don't need the iOS device - Safari will also link up to the iOS simulator, so you can do this with just XCode.
But XCode is MacOS only, isn’t it?
You can try Lambdatest.

https://www.lambdatest.com/feature