anderscarling

I’ve yet to use it personally, but renv [1] seems to try to solve the reproducible builds problem in a way more similar to other modern package managers (e.g. by generating a lockfile).

This approach enables stricter validations against tampering with the package repositories as a hash of the package can be stored in the lockfile, however it is obviously a bit more complex to use than the groundhog approach.

[1] https://github.com/rstudio/renv

I had some issues with this a few months back, and was in contact with apple dev support about it. They investigated the issue and since then it has worked for me.

Some people, me included, very much do. :)

Edited to add some background:

I feel it gives the tracks more context, especially as for many artists an album isn't just an unordered set of independent tracks but a carefully designed listing experience.

That said, I still like my playlists as well. ;)

I can't encourage people enough to actually set up their zsh manually instead of running a configuration framework.

I spent a few hours on this about a year back and went from over 2s to about 0.15s for a full run of an interactive login shell (`time zsh -l -i -c 'echo "test"'`). No functionality lost, at least none that I actually used and cared about.

Definitely one of the best quality of life improvements I've made to my setup in recent years.

I second this, world wide release would be nice. It's a shame how many "locale neutral" apps end up walled in on the US app store.

Is there any specific reason why this happens, just seems to me like you get worse reach and no benefits? Especially for a marketing stunt like this.

I remember testing Oj a few years back and finding that yajl where still faster for some cases, I believe it was very large arrays of thousands of objects.

I did some impromptu benchmarking now, and couldn't find a case where Oj performed worse than yajl. Impressive!

Larger files to store and upload to iTunes Connect mostly. I don't think bitcode is ever transferred to development devices.

I guess there is also a risk that the compilation process generating 3x larger files could also be slower as more work are being done - but that's just speculation.

That's troubling. :( Same for both swift and objC?

Would be interesting to see numbers for the compiled, stripped and thinned binary the end user will download from the App Store (they are in the details view for the app build on iTunes Connect). My guess is that at least most of the change should go away there.

With bitcode, app thinning and what not in the mix the Xcode build artifact is so much different from what's actually being downloaded it's hard to tell if this radar has real world implications for anyone but the developer uploading the build to apple. Still interesting, and potentially annoying though.

Incidentally, I run a startup - Tummy Lab [1] - that tracks food intake and analyzes the data for co-relations between food and stomach issues.

If someone is looking for partnerships with regards to keeping food databases, feel free to contact us!

[1] https://www.tummylab.com - swedish only, sry :/

Food tracking is an important part of many services, ranging from fitness/calorie tracking style apps to diabetes management.

However, keeping and maintaining an accurate food database is a big, costly, task that makes adopting new markets harder and obviously adds a substantial maintenance cost for each market.

Projects like this makes more markets accessible, especially small ones as cost per potential user is higher, and lay the foundation for cross-service-collaborations (i.e. log in your fitness app and the data shows up in your diabetes app as well).