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.
Only reasonable option I've come across so far is buying used hardware. VM under Win10/AMD seems like a PITA.
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.
It supports remote desktop and everything you would need
> Billing for EC2 Mac instances is per second with a 24-hour minimum allocation period to comply with the Apple macOS Software License Agreement.
> Billing for EC2 Mac instances is per second with a 24-hour minimum allocation period to comply with the Apple macOS Software License Agreement.
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!)
Are you saying that "aarch64" binaries don't run on all ARM chips?
https://news.ycombinator.com/item?id=28797129
404 points by nixcraft 11 days ago | 117 comments
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.)
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.
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.)
1. https://chris.improbable.org/experiments/browser/combining-h...
2. https://chris.improbable.org/experiments/browser/javanese-te...
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).
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.