Archive for August 8, 2019

Thursday, August 8, 2019

Windmill for iPhone Rejected From the App Store

Markos Charatzas:

For the past few months, I have been working on Windmill 3.0 which enables Windmill on the Mac to publish your iOS app.

Effectively, every time you make a code change, Windmill will also publish your app so that you can install it on your iPhone.

Markos Charatzas:

Unfortunately, Apple has firmly rejected Windmill on the iPhone. Windmill on the Mac does not seem to have Apple’s blessing either.

[…]

I was reminded of one very specific reason that I was given too.

Guideline 5.2.5 - Legal - Intellectual Property

YOUR APP IS TOO SIMILAR TO TESTFLIGHT, WHICH CREATES A MISLEADING ASSOCIATION WITH APPLE PRODUCTS.

[…]

More importantly. Apple took the stance that the Command Line Tools Package is only meant to be used by developers in-house and not by 3rd parties to provide support for continuous integration systems - continuous delivery in the case of Windmill.

Via Brent Simmons:

I don’t understand all the issues here, I admit, but I start by thinking that useful developer tools should be allowed on the App Store.

Update (2019-09-06): Markos Charatzas (Hacker News):

I don’t feel motivated knowing what is possible will be subpar, constrained, unwelcome, unappreciated and on the bad side of Apple. I feel crippled as an Apple Developer to make the best of all available platforms and technologies.

[…]

For Apple, this was just an app that was submitted, went through due process and was rejected. For me, this is a moment in time that will define what turn my life takes next.

Update (2019-09-09): gitpusher:

Former Apple + TestFlight employee here (3 years at TF + 2 at App Store post-acquisition) Apple is very territorial about developer tools. They do allow certain businesses (like Fastlane) to operate in this space (a tacit acknowledgement that those tools provide value) yet they deny others (like Windmill) the right to operate.

This follows the typical Apple ethos of “we can do it better because we’re vertically-integrated”. However this only works if your product is damn-near perfect. And Apple is infamously imperfect when it comes to software/services.

On top of the competence issue, they also have no real motivation to improve tooling. They know that developers will build stuff no matter how onerous the terms, and no matter how nitpicky is their approval process.

If they re-framed their perspective, and began considering devs as “users” in their own right, then perhaps they, too, would experience the tender love + attention that Apple lavishes on its end users. But this is simply not how they view it, and there is little political will inside Eddy’s org to accomplish such a shift.

Update (2020-01-06): Markos Charatzas:

The last version of Windmill on the Mac is 3.1.2. There are no plans to support Xcode 11 or any future versions of Xcode. Windmill on the iPhone never made it to the App Store.

GitHub Actions CI/CD in Beta

GitHub (tweet, Hacker News):

GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub. Make code reviews, branch management, and issue triaging work the way you want.

[…]

Hosted runners for every major OS make it easy to build and test all your projects. Run directly on a VM or inside a container.

Save time with matrix workflows that simultaneously test across multiple operating systems and versions of your runtime.

Free plans include 2,000 minutes per month, with extra macOS minutes available for $0.08 (10x the Linux price and 5x the Windows price).

GitLab:

And while we bet on this philosophy the industry is now seeing it as well. In September of 2015 we combined GitLab CI and GitLab version control to create a single application. By March of 2017, Bitbucket also realized the advantages of this architecture and released Pipelines as a built-in part of Bitbucket. In 2018, GitHub announced Actions with CI-like functionality built into a single application offering. In the last six months, JFrog acquired Shippable and Idera acquired Travis CI, showing a consolidation of the DevOps market and a focus on CI. The market is validating what we continually hear from our users and customers: that a simple, single DevOps application meets their needs better.

GitLab:

With about 3.44M job instances per week/13.76M per month, GitLab CI is growing at a rapid rate to help our customers and users with their deployment needs. Read on below to learn more about all of the exciting CI/CD features in the 12.0 series of releases that will help you to deploy your code quickly.

Previously:

Apple Is Locking Batteries to Specific iPhones

Jason Koebler (tweet):

A longtime nightmare scenario for independent iPhone repair companies has come true: Apple has tied batteries to specific iPhones, meaning that only it has the ability to perform an authorized battery replacement on the newest versions of iPhones, two independent experiments have found.

Battery replacements are among the most common repairs done by Apple and by independent repair companies. This is because lithium ion batteries eventually lose their ability to hold a charge, which will eventually make the phone unusable. Replacing the battery greatly extends the life of the phone: Apple CEO Tim Cook acknowledged earlier this year that battery replacements are resulting in fewer people buying new iPhones, which has affected Apple’s bottom line.

It’s concerning on many levels, then, that on the iPhone XS, XS Plus, and XR, that any battery swap not performed by Apple will result in the phone’s settings saying that the new battery needs “Service.”

Craig Lloyd (MacRumors, Hacker News):

Put simply, Apple is locking batteries to their iPhones at the factory, so whenever you replace the battery yourself—even if you’re using a genuine Apple battery from another iPhone—it will still give you the “Service” message. The only way around this is—you guessed it—paying Apple money to replace your iPhone battery for you. Presumably, their internal diagnostic software can flip the magic bit that resets this “Service” indicator. But Apple refuses to make this software available to anyone but themselves and Apple Authorized Service Providers.

Our friend Justin notes that there’s a Texas Instruments microcontroller on the battery itself that provides information to the iPhone, such as battery capacity, temperature, and how much time until it fully discharges. Apple uses its own proprietary version, but pretty much all smartphone batteries have some version of this chip. The chip used in newer iPhone batteries includes an authentication feature that stores the info for pairing the battery to the iPhone’s logic board.

Previously:

Update (2019-08-13): Rene Ritchie:

Some of the coverage has then focused on this being a move deliberately designed to hurt third party repair shops and it’s going to make Apple look really, really bad.

The first part is about as silly as saying right-to-repair is deliberately pushed to make a buck off selling high priced DYI kits. It’s just nonsense. Hurting third parties really sucks. Like really sucks. But it’s collateral damage. And it’s why the second part is bunk too. Apple doesn’t really care about looking bad with this.

What Apple cares about is catastrophic battery failures. Apple cares about that a lot.

Adam Engst:

I think Rene is significantly overstating the case. There have been third-party batteries available for Apple laptops and iOS devices for many years, and while it’s possible that dodgy parts or repair shops have caused problems, I can’t think of a single instance where that has reflected badly on Apple in a big way.

[…]

I’ll return to the car analogy. If you go to a lousy mechanic and get rebuilt or aftermarket parts that don’t work well, you complain to the mechanic, not Ford or GM. And more to the point, if someone does a terrible repair that results in an accident (which is a heck of a lot more likely with a car than an iPhone), no one expects that it will reflect badly on Honda or Toyota.

This is control freakery on Apple’s part.

Jerri-Lynn Scofield (via Hacker News):

I want to focus on one practical problem here: the dearth of Apple stores to conduct these repairs. This is a problem outside major US cities, as I understand there are big chunks of the US that lack Apple stores. This means people who live in these areas must now either schlep to an Apple store – or ship their iPhone – when they need a simple battery change (unless they are prepared to ignore bogus error messages). Uh huh.

Josh Centers:

Frankly, this is bush-league anti-competitive behavior on Apple’s part. Anyone who chooses to have an iPhone battery replaced by an independent repair shop—or opts to do it on their own—knows what they’re getting into. Independent car mechanics who rely on aftermarket parts have existed since the Ford Model T as an alternative to working with a dealer, and car owners have no trouble deciding which sort of business they’d prefer to patronize. That should remain true of computers and smartphones as well.

Update (2019-08-15): Rene Ritchie (tweet):

Apple sent me the following statement:

We take the safety of our customers very seriously and want to make sure any battery replacement is done properly. There are now over 1,800 Apple authorized service providers across the US so our customers have even more convenient access to quality repairs. Last year we introduced a new feature to notify customers if we were unable to verify that a new, genuine battery was installed by a certified technician following Apple repair processes. This information is there to help protect our customers from damaged, poor quality, or used batteries which can lead to safety or performance issues. This notification does not impact the customer’s ability to use the phone after an unauthorized repair.

[…]

No batteries are being locked out. That’s hyperbole, sensationalism, scare tactics.

It actually seems worse than blocking certain batteries, because it also complains about genuine Apple batteries that were merely not installed by a certified technician.

See also: Josh Centers.

A Year of Working Remotely

Mike Davidson:

First, let’s dispense with the easy part: despite what you may read on Twitter, remote work is neither the greatest thing in the world nor the worst. We are not moving to a world where offices go completely away, nor are we going through some sort of phase where remote work will eventually prove to be a giant waste of time. In other words, it’s complicated.

The way to look at remote work is that it’s a series of tradeoffs. You enjoy benefits in exchange for disadvantages. The uptake of remote work over the next decade will depend most on the minimization of those disadvantages rather than the maximization of the benefits. Reason being, the benefits are already substantial while many of the disadvantages will be lessened over time with technology and process improvements.

Via Mike Rundle:

I’ve been working remotely for ~6 years now and love it, so here are a few more tidbits I’d like to offer.

Colin Devroe:

That chatter that happens in office can sometimes bear fruit. Since these serendipitous interactions will no longer happen you have to create those interactions through deliberate action. Over communicate with your team about what you’re doing, what your ideas are, etc.

[…]

Meetings do not have to be terrible. There are some simple rules that I like to follow that help them suck less. Namely; Be certain you need an actual meeting, rather than an email or chat. Always give people enough time in advance to prepare. Always have an agenda. Always have action items. Follow up on those action items weekly or as appropriate.

Update (2019-08-13): Matej Bukovinski:

I’ve now been working remotely for more than 10 years and have faced many of these challenges myself, so in this post, I’ll be sharing some of my experiences and tips for making the most of remote work.

[…]

The company needs to be fundamentally set up for remote work, and it has to be the right fit for you personally. If either of those is not the case, you’ll have a miserable time.

Leakiest Abstractions

peterbourgon:

what are some of the worst/leakiest abstractions we’re currently dealing with in computers these days?

maybe things like: posix threads? the upper layers of the OSI model? the notion of a secure boot loader? OOP in general?

There are too many good replies to quote.

Previously: