This might have something to do with how data on GCP will be encrypted at rest. US law treats encryption effectively as a weapon and restricts where products that include encryption can be shared.
It’s a shame iOS just doesn’t seem to provide this level of data using public APIs as far as I can tell. I’d love to be proven wrong, or for Apple to be a bit more transparent regarding how they perform similar enhancements to location data.
I’m a loyal iPhone customer who likes the fact that Apple doesn’t give out API access willy nilly to apps and instead operates on a default-deny model. I’ll deal with the slightly inaccurate Uber dot.
What sorts of attacks or privacy leaks are possible from the APIs used by Uber to build this on Android? Information about each individual satellite seems like nearly useless data as an attacker, unless I'm a state actor trying to figure out whether you are inside or outside a building when aiming my drones.
I can’t think of any attacks now, and there may be none, but you can see the consequences of Google’s high level approach to APIs in the fact that Facebook snarfed up entire call histories for Android users but not iOS users.
This post makes no mention of the macOS part of the CircleCI infrastructure, which is one of the trickiest parts of infrastructure IMHO. Tricky because Apple's EULA prevents virtualizing on anything other than its hardware, never more than 4 VMs per host, and not for commercial purposes...
Apple's policy on VMs feels so backwards and it really bothers me. Apple expect you to have dedicated hardware if you want to do CI? It makes Mac/iOS projects a real pain and that's not including how much hassle Xcode only functionality is to script.
You'd think Apple would be interested in making the workflow for developers easier though so better apps would be made.
It's slightly better now but I've done iOS+Android mobile projects before where CI for Android has been easy to set up and CI for iOS has been a complete nightmare.
I think the workflow is pretty easy: buy a MacBook & an iPhone, and load your app onto the phone & test on it for things which the iOS simulator is not good at.
> I think the workflow is pretty easy: buy a MacBook & an iPhone, and load your app onto the phone & test on it for things which the iOS simulator is not good at.
> Don't CI your apps, CI your libraries.
That's not scalable for complicated apps that you can write automated UI tests for though.
Could you take the complicated bits and put them in a library? How complicated is your app?
To me, what you described is an app that was not designed to be easy to test component-by-component & will have a high overhead on maintenance. Apple’s restriction on virtualising MacOS seems unrelated to how the app was architected, so it feels unfair to expect Apple to alter their position to better support something they weren’t responsible for.
> To me, what you described is an app that was not designed to be easy to test component-by-component & will have a high overhead on maintenance. Apple’s restriction on virtualising MacOS seems unrelated to how the app was architected, so it feels unfair to expect Apple to alter their position to better support something they weren’t responsible for.
We have complex commercial apps with fully automated user interface tests (e.g. it'll test that you can enter your username + password, actually login and you'll be able to see content). You could test all the individual components as much as you want but you're still going to get bugs at the UI layer that you can automatically test for.
We do the same for Android and CI for that is so much simpler.
> Apple’s restriction on virtualising MacOS seems unrelated to how the app was architected, so it feels unfair to expect Apple to alter their position to better support something they weren’t responsible for.
You'd think they'd want to support workflows that led to better quality apps being created. Surely it's their responsibility to support developers?
> you're still going to get bugs at the UI layer that you can automatically test for
Surely you can prove the correctness with integration tests of your modules, and then your acceptance tests can be simple 'did the thing not show an error when we clicked on the thing, and it went to the right page'? We have 'simulate the world' 'acceptance' tests at work and they're terribly flaky, and I look back at the layered approach to testing we used in a previous job where the go-live test was to hit the landing page & search results page & check that the status code was 200.
To be fair, the kind of tests I'm proposing won't catch layout issues. But, neither will the tests you're using.
I'm not saying it's always a good idea to write exhaustive UI tests but it's nice to have the option. There's apps that I've worked on where you simple must test several business critical UI interactions haven't broken (e.g. logging in, submitting data) before you deploy. Apple getting in the way of automating this without a decent reason is annoying.
What made your UI tests so flaky? As long as the code for them isn't much beyond "enter text into text input X, click this button, you should be able to see this text" they're not too bad to write but the initial setup can be tiring.
> To be fair, the kind of tests I'm proposing won't catch layout issues.
Screenshot comparison based tools can be amazing for this as long as the way your app looks is fairly stable.
Automated testing is always a tradeoff with effort to setup vs the time you save (I'm against e.g. TDD for everything) but for complex apps and big teams it eventually pays off.
But most of the hardware sales are iPhones. Mac sales are dominated by portables, and I doubt that many serious providers are hosting anything off of MacBooks.
Apple just needs to handle the build process themselves. Let me upload my app code and you do all the hard work. It's not like I can deploy to other app stores...
Not quite sure if I understand the question, but we've been using their iOS product for a couple years now and have appreciated their support. They upped their game last year with a key hire or two, although there were growing pains.
Overall we are happy with it. I don't think CircleCI 2.0 is available yet for iOS, though, so nothing new to discuss yet.
On the topic of QA testing/automation, it really kills me that Apple servers won't sign older iOS releases which means QA teams need to protect stock devices from accidental upgrades. The AWS Device Farm iOS devices are all jailbroken.
What's the commercial usage limitation? Is that specifically for virtualization of OSX to prevent offering a "Mac On Demand" by not letting you run the OS itself?
Turns out it's two, not four VMs. From macOS Sierra's EULA[0]:
> (iii) to install, use and run up to two (2) additional copies or instances of the Apple Software
within virtual operating system environments on each Mac Computer you own or control that is
already running the Apple Software, for purposes of: (a) software development; (b) testing during
software development; (c) using macOS Server; or (d) personal, non-commercial use.
With c) you're allowed to run up to 2 copies. It doesn't really help you run a hundred containers on a powerful server... (Not that you easily legally could, as I guess the moat powerful Mac hw available is the Mac pro - not exactly great for rack deployment).
[ed: i guess you mean running os x server is an alternative to "non commercial use" - I agree with that reading. The option for nc use seems like a nod to not completely make experimentation and creative development/research entirely illegal.]
Maybe this would lend itself well to parsing bitcode slices (serialized LLVM IR). I've often wanted to diff bitcode produced by different compiler versions.
What's wrong with llvm-diff [1]? Is it that you want to compare across bitcode versions that weren't backwards compatible? (so the current llvm-diff won't parse an old old bitcode)
llvm-diff is indeed pretty great, but having the IR structure as an AST that you could programmatically access and manipulate would allow more semantic diffing, or integration into workflows that would benefit from structured representations of a diff.
