Every episode of The Talk Show is gold but I’m especially enjoying this one. This line cracked me up.
Yesterday, Scott Adams announced a hackathon for 3 different contests surrounding his WhenHub app.
A goal-oriented startup would have a specific customer and a specific product in mind. If that doesn’t work out, the startup might have enough cash left over for a pivot, or maybe two, to try again. But in each case, there is a specific goal. And the way startups work, the odds of any particular startup hitting its goal is dismal. That’s why WhenHub was designed from the ground-up to be a systems business model instead of a goal-focused model. The idea is to get something like a portfolio effect to increase the odds of at least one of the things we’re doing becoming a profitable line of business.
Now we’re taking it up a notch by running an online hackathon for our WhenHub platform.
Being systems-oriented sounds good in theory and it works in certain situations - evidently it worked for Donald Trump - but when it comes to a product, it doesn’t work. What Adams needs is a very clear product and value proposition while simultaneously being willing to pivot by listening to what the market tells him. Instead, he has an ambiguous product that he’s attempting to crowdsource into existence. What does WhenHub do, and why do I need it? That question needs to be asked and answered succinctly and satisfactorily. The fact that it can’t be is worrisome.
This morning I cloned the WhenHub/mycomposer repo and played around with it some. Going through that process was buggy. I had to re-clone the repo several times before the system dynamically populated my instance’s manifest.json variables to my own data. And even then, because it wasn’t bulletproofed to handle repo deletion and re-cloning (despite it prompting for this), the css and js folders didn’t exist, so I had to manually copy them from a zip version of the original.
Once I was finally working - it took me over an hour, and I consider myself decently well versed in how to set up front-end environments - I got to looking at the actual JS code. It’s all in ES5, not ES6. This tells me right away that the developers aren’t living on the edge. They aren’t hustling. Scott’s not surrounding himself with a Class A team. Now admittedly, doing that is tricky when you’re not a developer yourself and don’t know what to look for. But man. I went from thinking, It’d be fun to take a stab at one of those $4,000 prizes, to thinking, I could spend the same amount of time elsewhere on a guaranteed gig, make the same amount of money, and actually get to work with a code base that I’m not cringing over.
So we’ve got:
- A product that’s a non-product, one that glories in the fact that it doesn’t know what it is yet.
- An interface that’s as bloated as Microsoft Word.1
- A code base that’s full of holes and lives in the past.
I’m going to leave this hackathon to others. It’s fundamentally flawed in ways that I can’t help it. I’m reminded of a comment that a Dilbert Blog reader left about it.
There is an idea behind it, it’s the execution and presentation that sucks, something that [Steve] Jobs would eat the developers alive for.
The idea might suck too, but we’ll never be able to tell.
Yeah, pretty much.
Not actually that bloated. But definitely too busy and way too many borders and box shadows. ↩︎
With Micro.blog coming out soon - the invite-only beta is already available - having the ability to publish to a Jekyll powered site from an iOS device is a must. Kirby Turner has put together a good resource here on how to publish to a Jekyll site directly from an iPhone. I’ve sort of wanted the ability to do this in the past, but with the imminent launching of Micro.blog, this is soon going to become a must. The idea is that you need to be able to publish something to your site - which gets syndicated to Micro.blog - as easily, or almost as easily, as opening Tweetbot and posting a tweet. Until we get to that point, this isn’t going to take off.
I’m not going to rest until I’ve got a similar setup going on over here.
I’m reading Web Performance in Action by Jeremy Wagner and one of the things he introduces is NPM’s html-minify module. The performance benefits are undeniable plus it just looks better having the source all consolidated. Here’s how to do that in Jekyll, which you’ll notice I’m now doing on this site.
It used to be the case that if you
⌘click Finder arrows in macOS, it would be the equivalent of
⌘click Safari arrows. In other words, it would perform the same action as a regular click - going forwards or backwards in history - but it would load the new view in a new tab.1 That’s no longer the case, and I think macOS 10.12.4 is the first version in which this is true. It’s possible the change was introduced earlier, but I didn’t notice until 10.12.4. For a while I thought this was a bug but today I realized that it’s intended to be a feature. Going forward, when you
⌘click the Finder arrows, you trigger an ability to rearrange / remove the customizable items in the Finder bar.
I’m not happy about this change for two reasons:
- It creates ambiguity about what
⌘clickdoes on arrow buttons. It’s no longer consistent across the apps. Finder and Safari (and all other browsers) are now disjointed.
- It’s much more common to need to open a Finder history in an enclosing window than it is to rearrange or remove the items in the Finder bar. Once you’ve got your Finder bar items set the way you want them, you’re done. That’s a once-every-six-months sort of thing. Navigating through history on the other hand is a daily task for some people.
⌘click functionality in Finder is not limited to the arrow keys. It’s available on any customizable item in the Finder bar. In asking for Apple to restore
⌘click on arrows to their former functionality - that of opening in an enclosing window - I’m aware that I’m asking for
⌘click to do different things in the Finder bar depending on what you click on. I’m ok with that.
⌘click on the title in the Finder bar already does something different anyway: it shows a dropdown menu of items, each of which is a shortcut to the previous item’s parent directory, starting with the current directory and traversing past Macintosh HD all the way to the very root (i.e. “Devices”).
If performing the same action (
⌘click) on different looking things (e.g. Finder arrow buttons and Finder search) in the same area (Finder bar) results in different outcomes, that’s not inconsistency. If performing the same action on similar looking things in different areas results in different outcomes, that is inconsistency.
For quite some time, it’s been rumored that this year’s iPhone is going to have two tiers with noticeably different industrial designs. From Mac Rumors:
Japanese site Mac Otakara believes the iPhone 8 might actually be called the “iPhone Edition,” after the higher-end Apple Watch Edition models. Such a name would reportedly reinforce its position as a high end iPhone that’s meant to be sold alongside two standard iPhone models.
And then this morning from The Verge:
2017 marks the iPhone’s 10th anniversary, and the rumors are that Apple will be releasing three new models to celebrate: two handsets with incremental improvements, and a third, radically redesigned “premium” iPhone.
Here’s what bothers me about this. If Apple does this, then it’s essentially saying that a full screen iPhone isn’t for everyone. It’s only for the people who really want it, who are willing to splurge. That might be ok, except that the Galaxy S8 has this premium screen, and the Galaxy S8 isn’t a “premium” or “luxury” SKU. It’s the de facto in the Galaxy lineup.
In other words, Apple is saying this: what our competition views as essential, we view as a splurge only for those who want to pay us even more exorbitant amounts than they’re already used to paying. That really rubs me the wrong way.
If Apple’s baseline 2017 iPhone had everything the Galaxy S8 had to offer and then its premium iPhone had even more, that’d be one thing. But that’s not what I’m hearing through the grapevine. Instead it sounds like if you want an industrial design that’s visually similar to the Android competition, you’re going to need to go all the way to the top of Apple’s pricing tier. You shouldn’t have to do that. The subliminal message that Apple is emitting in its rumored decision here is unsavory.
Earlier this week, Twitter CEO Jack Dorsey contacted me to discuss my ongoing public observations that Twitter appears to be “shadowbanning” me because of my writings about Trump. Jack introduced me via Direct Message to Del Harvey, Twitter’s Head of Trust & Safety, for the official answer.
The official answer is that no one, including me, is shadowbanned on Twitter. It has never happened.
There are about four possible explanations at this point.
- Twitter is outright lying. I find this extremely unlikely. I’m leaning towards taking Twitter’s statement at face value.
- Or employees lower down the food chain are monkeying with tweet visibility and their superiors are blissfully unaware. This sort of thing is farfetched, practically unheard of, and can cost a developer his job, so I think we can rule this one out.
- Or there’s a conveniently partisan bug in Twitter’s software.
- Or this is a clear example of confirmation bias, and Scott is living in a delusional world.
Something strange is afoot. The last option seems the most likely, but there’ve been an awful lot of incidents that are hard to explain away to pure chance.
When you sign up for Dropbox, you get 2GB of space. If you want more than that, you can earn it by referring other at 500MB per referral. That’s not much space, however, so more than likely you’re going to need to upgrade to Dropbox Premium which starts at 1T.
This is a sensible business model because it Dropbox’s only source of revenue. Selling storage is what Dropbox does.
But why does Apple think it needs to charge for its premium storage in iCloud? You cannot have more than 5GB with a free plan. From Apple Support:
When you sign up for iCloud, you automatically get 5GB of storage. You can use that storage for backups, iCloud Photo Library, iCloud Drive, Mail, and more.
It’s possible to sign up for iCloud without owning any Apple devices, but how many people do that? I’m going to say that number is small - very small. The overwhelming majority of people who own an iCloud account have spent many hundreds if not thousands of dollars on Apple products. They should have more storage than 5GB in iCloud.
When you buy an Apple Device, you should get as much iCloud storage as that device can contain. The pain and annoyance of not having this is much more tarnishing to Apple’s brand than the revenue that Apple would lose from having it. This is the exact argument I made for the Mac Pro. Not selling a Mac Pro is more of a financial problem in the long run for Apple than losing money1 by developing and selling a Mac Pro.
I was reminded of this frustration today because my iPhone cannot back up to iCloud unless I upgrade to premium. It wouldn’t hurt me to pay the $11.88/year, but it’s the principle of the thing. You spend $2,000 on a MacBook Pro and then Apple tells you to spend 99¢ per month with them so you can store 50GB of that data in the cloud. That’s disgraceful and insulting. It’s the equivalent of being at a high end steakhouse and the waiter telling you that bringing a wet towel at the end is going to be an extra 99¢, please confirm. The price of that towel should not be something you’re aware of. It should be bundled in the overall price of the meal. The overall experience. Of course hosting data in the cloud costs money. Apple’s users should still have to pay for it. But that method of payment should be bundled in the cost of the devices, which are arguably marked up enough to not need a price bump just to include this.
And then for the iCloud users who don’t have activated Apple devices, well, let them pay. Or make it mandatory that you own an activated Apple device to use iCloud storage.
That’s relatively speaking, from an opportunity cost standpoint, compared to investing that money in the iPhone. If Apple actually runs at an operational loss on the Mac Pro then something’s badly wrong. ↩︎
From the Slack blog:
Let’s say you’re stepping away from Slack for a bit — maybe you’re grabbing some lunch, taking a week off, or even just focusing on a task for a few hours. Now you can set a custom status in Slack to share what you’re up to, when you’ll be back, whom to contact in your place, or anything else that helps your team know when they can expect to hear from you.
I actually fully expect Slack to dial this back at some point. The concept is great but the implementation is too busy. When you set a status update, it appears in the following places:
- In the sidebar.
- In the text box that people see when they message you.
- In your profile header.
- At the end of your name, everywhere you write messages.
The idea of a status is a great idea in one or two places, but having it in these four places is just too much. Even if only 1/3 of the people in your Slack channel implement this feature, it has the result of getting way too busy. The overall UI looks more like a child’s toy than a serious application for professional communicating.
Every maturing company fights against bloat. Some more than others. Some companies fight tooth and nail at the expense of not looking like they’re innovating. Others fight so little that you get the feeling that the place is turning into a cluttered junk yard. Finding that balance is hard.
I just finished listening to Thermal Corner, the first ATP episode that came out after the new Mac Pro was announced. Everyone at Apple should listen to this episode, particularly the word of caution at the end. For Apple to continue to update this new Mac Pro, people are going to need to buy it. But in order for them to buy it, they’re going to need confidence that it’s a product that Apple is truly invested in and won’t abandon. And Apple must prove that by issuing new updates to it every year. That’s the only way Apple’s going to restore the confidence and trust that was broken with the 2013 model.
It makes sense that Google shut this down, but man oh man.
Vlad Savov, writing for The Verge:
I’ve been reading about Gcam, the Google X project that was first sparked by the need for a tiny camera to fit inside Google Glass, before evolving to power the world-beating camera of the Google Pixel.
Well, ok. So you think Google’s camera is better than Apple’s. It’s a free country, so we’ll move on.
What if your phone knew when, where, and what you’re pointing it at; what if it had a library of trillions of images; and what if it could intelligently account for things like weather and time of day? Would it need to have eyes to see the scene you’re trying to capture? […]
Tell your phone how tall you are and, with the help of the same orientation sensors it uses to know its place on a map, the device will be able to calculate both your subject and your point of view when you want to shoot a photo. And if it’s something as ubiquitously photographed as, say, the Roman Forum, all a future Googlephone would need to know are the cloud formations and Sun position at the particular time of the shot, and it’d have enough data to synthesize a photo.
I don’t know where to begin with this, other than to say that it’s never ever going to happen. Ever. Phones aren’t going to lose their cameras because of artificial intelligence. You can already do what Vlad is suggesting by going to Google Images and pasting in people’s faces with Adobe Photoshop. All he’s talking about is an automated way to do this. Using this exclusively in lieu of a camera is madness. How is it anything other than a huge step back from where we currently are? The whole point of a camera is to say, “I was here, and this happened.” Neither one of those things happens with Vlad’s idea. You don’t have to be anywhere, and you won’t be able to capture anything special. This Verge piece doesn’t seem to comprehend the basic reason for mobile photography.
For the longest, I’d thought that a JS file being in the
<head> tag versus immediately after the opening
<body> tag would make a difference perf-wise and render-wise. Turns out that’s not the case. Putting a script immediately before the closing
</head> tag or immediately after the opening
<body> tag makes zero difference. They’re both render blocking, unless you use the
async property. This is one of those I can’t believe I didn’t know that years ago things.
Nilay Patel, writing for The Verge:
At the end of all this, it really just seems like Apple thought people were fine with the iMac and MacBook Pro, didn’t want to throw resources at the Mac Pro, and got blindsided by the reaction of their most loyal fans who depend on high-end Macs when the Pro lingered and the MacBook Pro was a little weirder and slightly more underpowered than expected. So the course was corrected, and here we are.
I would say that certain people at Apple thought everyone was fine with the iMac and MacBook Pro, but I would not say that it was everyone. If it’d been everyone, the Mac Pro would not have remained in its outdated form for so long on the store. What we have here is a tale of two different factions within Apple. The Cook faction wanted to kill the Mac Pro altogether, while the other faction wanted to remake it. Neither side prevailed until 2017, and then the right side won. And the right side won because the Cook faction finally saw “the reaction of their most loyal fans who depend on high-end Macs.”
- It’s a relief that all the speculation drama is over.
- This is the most important piece on Daring Fireball for a long, long time. Parts of it read like a lengthy article from a professional journalist at the New York Times or The Atlantic. That’s unusual, unexpected, but delightful.
- Tim Cook’s efficiency mindset was the primary road block to this. There’s zero doubt of that in my mind. There has been an internal conflict in Apple for years now. The conflict in the abstract is this: do you focus exclusively on making the company more profitable or are you the people’s hero, the company that does the right thing simply because it’s the right thing? The paradox is that when you do the latter, that’s what makes people love you in a fanatical way, which in turn makes your company financially profitable in a way that could never happen if you focused exclusively on profit.
- When did Apple start working on this new Mac Pro? I’d bet my bottom dollar that this decision was made in 2017. Not a day earlier. It took that long for people to convince Cook and those that shared his mindset to green light it. Building this Mac Pro to accommodate 1-3% of the Mac market is an unprofitable venture compared to spending that money on the iPhone. If I were at Apple trying to persuade Cook, my persuasion would have been focused on brand perception: that in the long run, Apple would lose more money not making the new Mac Pro than making it.
- Regarding the question of why Apple didn’t update the Mac Pro sooner, that one’s easy. It’s the same reason Apple didn’t start building the new Mac Pro sooner. It’s because a portion of Apple really did plan on abandoning the Mac Pro. Don’t tell me with a straight face that everyone at Apple for the past 3+ years has been planning on continuing the Mac Pro. The gatekeepers couldn’t have cared less. And this goes all the way to the very top of the company. No, it took the outcry of the community through articles and podcasts and voting with their wallets to finally tilt the scales. And then once the company was committed to the Mac Pro once more, it made sense to give speed bumps to the preexisting one. Also notice how seemingly effortlessly Apple updated it, too. What did it take, a few hundred man hours total? That’s undeniable proof that if the company had been committed to the Mac Pro all this time, it would have done this years ago.
- The fact that some people at Apple were against continuing the Mac Pro and others were for it explains why so many bright pundits fell to each side of the debate. We were getting mixed signals and we interpreted them differently. This is The Prestige writ corporate.
- That Apple had unilaterally completely turned its back on the Mac Pro and standalone displays was something I never could convince myself. My gut was less based on evidence (other than the current Mac Pro not being discontinued) and more on a feeling of, there’s no way Apple would actually leave the Pro market.
I’m sure there are people in the Gnu PGL community who are nice, but this sums up the community’s general attitude towards licensing better than anything I’ve ever seen. Specifically WordPress’.
When the late 2016 MacBook Pro with Touch Bar came out, I wanted it so badly. But after listening to this podcast, I don’t feel the need for it. About half the Internet feels the same way, apparently.
If you’re on GitHub every day as much as I am, these shortcuts are valuable. My favorite one is
On Wednesday of this week, Stack Overflow released the survey results from the 2017 survey. There are a lot of little nuggets that are fascinating to dig into. Here are a couple of big takeaways.
- The wording on the question for operating system was very ambiguous. It wasn’t clear if it was asking what platform you were writing for or on. Amazon Web Services was an option along side Windows Desktop and Raspberry Pi. That’s very strange. The result is that the number of people who specified Mac OS (a compromise term that combines both Mac OS X and macOS) was just 18.4%, down from 26.2% from last year. This is misleading. If the survey had asked the question as clearly as it did previously, Mac OS would be in the 30% range.
- Working remote is becoming more and more of a thing. 53.3% of developers looking for a new job say that remote options are a top priority? That’s huge.
I hadn’t known before today that Find My Friends was available on macOS. I wish it were a standalone app like it is on iOS, but this will do for now.
On the flipside, I, for one, view Uber’s regulatory maneuvering in a much more positive light.
One of the great things about Ben is that you can depend on him to be against overt regulation and oppression of business. I’m glad to finally see someone say this.
Then this nugget:
Moreover, one of Uber’s other “scandals” — the fact that Kalanick asked Amit Singhal to step down as Senior Vice President of Engineering after not disclosing a sexual harassment claim at Google — reflected far worse on Google than Uber: if Singhal committed a fireable offense the search giant should have fired the man who rewrote their search engine; instead someone in the know dribbled out allegations that happened to damage a company they view as a threat.
Everyone’s talking about how horrible Uber is, but Uber isn’t alone in this.
The sad truth is that for too many this is the first case of sexual harassment they’ve cared about, not because of the victim, but because of the potential for taking Uber down.
Uber isn’t a perfect company. But the app is still on my iPhone and I continue to look forward to using it. Ben’s done a service to the community. He’s done the delicate job of analyzing the positive aspects of Uber without looking like an uncaring misogynist.
Today I upgraded to Beta 5 of macOS 10.12.4 and discovered that it breaks commit signing in tmux. If you’re using pinetry-mac and if you have
commit.gpgsign set to
true in your git config, then every time you make a commit, pinentry-mac is supposed to auto-supply the GPG passphrase from your keychain.1 What happens however with Beta 5 is that pinetry-mac doesn’t work specifically in tmux. It works in Terminal and iTerm just fine, but if you try to use tmux in either of those programs, it doesn’t work.
What are your options? You have a few.
First, you could revert using Beta 5 and go back to the latest stable version of macOS. I’m not going to do this because Night Shift on macOS beta has become indispensable for me. I use it 24x7.
The second option is that you could quit using tmux, but tmux is a must for me. This is a non-option.
The third option is that you could quit using pinetry-mac and just supply the password everytime. To do this, just modify the
~/.gnupg/gpg.conf file by removing this line:
This would get laborious though, having to manually paste in the GPG passphrase every time.
The fourth option, the one I’m going with for now, is just disabling commit signing for now. Commit signing is very cool and I like the green “Verified” badge that comes with it, but it’s not a huge loss to no longer have this. Disabling commit signing is as easy as running this:
Update: here’s the fix.
Of course, you have to supply your GPG passphrase to pinentry’s dialog window the first time you’re setting this up. ↩︎
Casey Newton, writing at The Verge:
On Tuesday morning, members of the S3 team were debugging the billing system. As part of that, the team needed to take a small number of servers offline. “Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended,” Amazon said. “The servers that were inadvertently removed supported two other S3 subsystems.”
Someone enters the wrong command in Terminal, and next thing you know, entire websites are down and people can’t turn on their IoT lights in their house. That’s one powerful Terminal window.
This morning I made a prediction on Twitter that this year’s new industrial design iPhone will have a USB-C port.1 To my thinking, it makes perfect sense that Apple would do this, and perfect nonsense that Apple would not do this. Let’s look at the timeline.
- September 2012: Apple ships the iPhone 5 with Lightning.
- August 2014: USB-C spec is finalized.
- September 2016: Apple ships the iPhone 7 with no headphone jack.
- September 2017: Prediction: Apple ships an iPhone with USB-C.
Here are some reasons for my prediction. First, Lightning existed only because USB-C wasn’t finalized. The timeframe at which Apple realized it needed to actively make steps towards ditching the 30-pin connector was likely around 2010, or early 2011 by the absolute latest. USB-C as a finalized spec was nowhere in sight - it had four more years to go. If USB-C as a finalized spec had existed in 2010 or 2011, Lightning would have never been needed. In other words, the one and only reason that Lightning made sense is now gone.
Second, moving to USB-C gets Apple closer to port consolidation and interchangeability. Lightning is exclusive to iOS, which means it’s not that helpful compared to a universal option. Right now, if you buy the newest MacBook Pro and the newest iPhone, you cannot connect the two without buying an adopter. One easy fix for this, without Apple changing from Lightning to USB-C, would be for every new iPhone to come with a Lightning to USB-C cable as well as its current Lightning to USB-A cable. That’s a very specific cable though. It would be more useful and interchangeable if the iPhone came with a USB-C to USB-C cable. The idea is that Apple slowly moves us to a world where everything is USB-C. Your laptop, external monitor, iPhone, and iPad all connect with USB-C. See how simple that is? No Lightning, Thunderbolt, or USB-A. Just USB-C, which is very small and can do everything that those others can do. This is a very Apple-like thing to do. It makes good sense. There’s no reason this can’t be the future, if Apple’s willing to be brave and face the criticism.
Third, if Apple was not planning on moving the iPhone and eventually iPad to USB-C, why would it have made the MacBook and 2016 MacBook Pro use USB-C instead of Lightning? It’s not like Apple’s customer base had tons of USB-C cables in use with preexisting Apple hardware. There would be no compelling reason for Apple’s laptops to use USB-C instead of Lightning unless the iPhone and iPad were eventually going to also move to USB-C.
What about reasons Apple would not want to do this? Let’s look at Gruber’s well thought reasons against it:
If Apple had any plans to switch from Lightning to USB-C, why wouldn’t they have switched last year with the iPhone 7, when they started making tens of millions of pairs of Lightning ear buds?
This is a fair point, but I think there’s explanation. First, the Lightning ear buds come with every iPhone. Every time you buy a new iPhone, you get new ear buds. If 2016’s earbuds were Lightning and 2017’s earbuds are USB-C, it’s not a huge setback from an Apple manufacturing and cost standpoint. From a user standpoint, it’s potentially frustrating that a year-old pair of earbuds would be incompatible with a 2017 iPhone, but that’s only going to bother you if you lose, give away, or break your 2017 earbuds and want to use your 2016 pair. Those things could happen but they’re fringe cases, and Apple doesn’t base its decisions on fringe cases.
This explanation still doesn’t address Gruber’s main question though: why wouldn’t they have switched last year with the iPhone 7? There’s a couple of reasons I can give. First, Apple didn’t want to have to change the industrial design of an iPhone that would otherwise look exactly the same as the iPhone 6S. Better to measure twice and cut once. Don’t force an industrial design change until an iPhone release that actually looks different and justifies the cost of retooling and a new incompatible body. Sure, this would mean there’d be a cost in designing 2016-exclusive earbuds, but that’d be substantially lower than the cost in tweaking the industrial design of the iPhone 7.
Another way of explaining it is this. The industrial design of a new iPhone is set in stone a minimum of 12 months before the release date, according to Gruber. Apple probably works on that new industrial design at least 6 months, probably closer to 12. This means that if Apple had wanted to introduce a USB-C iPhone in 2016, it would have needed to begin exploration of that by early 2015 at the latest. Perhaps even late 2014. The spec for USB-C had barely come out by then. There wasn’t time.
Either because of money or time constraints, or both, it just wasn’t feasible having USB-C in the iPhone 7.
Then there’s this bit:
My expectation has been that iPhones will never switch to USB-C — that Apple would stick with Lightning until they can do away with external ports entirely.
I’m not convinced that a day will come in which iPhones have zero external ports. To me, that makes about as much sense as having no physical power button. It’s technologically possible, but impracticable. There’s a good case to be made for not having more than one button or more than one port, but there’s also a good case for needing that one button and one port. The only universe where it’d make sense to completely remove the ports is a universe where: (1) wireless connectivity protocols have 100% uptime and zero possibility of interference or breakage (2) compiling code to an iPhone wirelessly is just as fast as compiling code with a hardwired connection. Maybe we’ll someday live in that world, but I don’t think it’s coming in the next decade. It’s ok to promote wireless with a fallback of wired, but to exclusively offer wireless is a disservice to developers and people who care about speed and reliability over aesthetic.
Then there’s the argument that the USB-C port is thicker than Lightning. That’s only barely true, and I don’t think it makes a difference. Maybe we’ll get to a point where the thickness of USB-C is actually a determining factor in smartphone thinness, but we’re quite a few millimeters away from that actually being a discussion. Either port would fit just fine in the iPhone 7, and presumably for this year’s iPhone too.
I’m with Federico:
I’m leaning towards USB-C everywhere […]
Predictions are one thing that Twitter is good for, since its timestamps don’t lie. ↩︎