I've been saying for years that we need a new App Store. With the Epic/Apple battle being played out in public, I figured I'd describe my current vision for a new App Store model that better serves users today. The obvious answer is just to move iOS to a macOS like system but it's just as obvious Apple isn't willing to do that. My proposal is a compromise that I believe offers a fair direction forward for all parties involved.

First, let me describe the assumptions I'm working with. I'm sure I'll miss something, hopefully nothing that would drastically affect my proposal though. Of course, message me if you think I need to include something I haven't and I'll add updates.

Some Assumptions/Assertions:

1. It's impossible to create an environment that is both useful and 100% safe. Just being alive puts you in danger. This is normal. The goal isn't to be 100% safe, it's to find the point at which users are reasonably safe while still being functional. Anyone that tells you the current situation is 100% safe is lying to you. Arguably, it's also a disservice to tell people they have no risk, or even create a situation where there is no risk.

   Example 1: Even though viruses/malware are rare on macOS, computer experts should never say "get a Mac, they don't get viruses," since then users would think they're safe to just download anything anyone tells them to.

   Example 2: Outside of tech, take the case of playgrounds. In "the old days," as a kid, you could go to the playground and slice your hand on a rusty part, or fall 20 feet from a climbing cage. New regulations made playgrounds ultra safe, all plastic bits, no sharp edges, nothing high enough that you could fall and break a bone. Not only does this create a false sense of security since you can still fall and break something from ground level, it also takes away the opportunity for kids to learn how to evaluate risk.

   Since things can never be 100% safe, it's important for people to also consider the possible outcomes of doing something. Ensure they consider what can happen if they grant an app access to their photos. Think about why a dialog is asking for their password. Teach them to manually save documents as they're working, even with auto-save, sometimes things go wrong. Teach them to make backups on a regular basis, "just in case". Funny story: I wrote the first draft of this post on my iPad in a beta version of an app. When I came to proofread the next day, the beta had expired and the app was no longer in TestFlight. I'd been copying it into Notes every hour or so "just in case" and well, case happened.

2. The App Store itself does not add to the security of iOS devices. Security is provided by various technical means such as user permissions, sandboxing, certificates, kill switches, etc. Some would include App Review in there, but that system is fallible, as we've learned.

3. Different things require different levels of security. For example, personal information such as your name and government identifying numbers require the highest level of security. Photos, contents of emails, contacts etc. require a high level of security, but not quite as high. Payment details (credit card numbers) would be next in line requiring a medium level of security. The reasoning for this is that if someone compromises your government ID, they could cause all kinds of irreparable damage, but if someone gets your credit card number, it's mostly just an inconvenience since fraud happens so often the credit card companies have systems in place to reverse the damage. After all you're giving your credit card number to pretty much every company you buy stuff from online. Not to mention your physical card broadcasting the info to anyone with an RFID reader in their pocket.

4. Apple isn't the only company you can trust with your credit card number.

5. Everyone involved in the app ecosystem wants a fair system. Companies or individuals that want to leech off the work of others without contributing something back are not worth the time to consider.

6. No company should be able to dictate if another company can sell their product/service. That's a job for governments.

7. Apple is not a government.

8. Apple builds iOS and the API used by developers for themselves. This isn't something they've built as a service to developers and for which they need to be compensated. They built iOS and its API's before they ever considered an App Store and allowing third party developers to build apps for the platform. The concept of the App Store was originally implemented by jailbreak users in the iPhoneOS 1.0 days called Installer.app (Wikipedia).

9. Apple means well, but might be too over-protective for their own good.

My Personal Notes

Second, let me state that my personal opinion is that Apple's fee of 30% is not a problem in itself. The problem with the 30% fee is forcing it on developers and not allowing them a choice of service provider. Apple seems to truly believe they're offering value for that money, so opening things up gives them an opportunity to prove it.

More than that, my biggest complaint with Apple is the power they have to decide if another company should be allowed to provide their product/service. They are able to block any app that competes with them (now or in the future), is innovative in any way Apple hadn't considered, or that goes against their values. Apple shouldn't be allowed to project their values onto their customers. If their customers want porn apps, so long as they're legal, they should be able to buy and install them. If customers want to run an app that devours their battery, they should be allowed to do so. It's important to realize that Apple saying "Company X can't sell Y" is the same as saying "Customer Z can't buy Y even if they understand the implications".

The Proposal

With all those points out of the way, here's my proposal for a new App Store model that aims to solve most of these problems.

Apple keeps App Review in place with some changes. Apps are graded into quality tiers:

1. rejected: illegal — this one will need to handle various jurisdictions
2. rejected: malware — attempts to circumvent device security etc
3. accepted: excluded from App Store — low quality/goes against Apple's values/competes with Apple/whatever else
4. accepted: allowed in App Store — high enough quality to be promoted in the App Store

The key difference being that Apple accepts anything that isn't illegal or a valid security issue, but not every accepted app gets listed in the App Store. An app that has been accepted, but excluded from the store can be installed by a user that has a direct link provided by Apple upon approval. Side note: this gives Apple a great opportunity to optimize the App Store since they can remove the millions of junk/neglected apps and only present the best apps to users.

Next, Apple allows alternate store fronts, I'll call these Store Front(s) as a generic term to differentiate from Apple's App Store. These are apps that act as alternate stores users can use to find and install apps. They can include search, categories, editorials, or none of these, it's up to that store runner and how they think they can best serve their users. Store Fronts can list apps that are included, or excluded from the App Store. When a user installs an app from a Store Front, it uses Apple's API to install the app from Apple's servers.

Note, so far, all of this is possible with today's tech already in iOS. Store Front would be just like TestFlight, installing apps securely from outside of the App Store.

Handling payments in Store Front would be something new. While I assert above that Apple isn't the only company it's safe to give your credit card info to, let's stick to exclusively using Apple's payment system in this first step forward. When a user installs a paid app, it still triggers Apple's payment system, same as now, and calls back into the Store Front app with a success or fail response if the purchase (and install) was successful. When the app is installed (paid or free) from a Store Front, the receipt records which Store Front was used in order to handle commissions for the initial sale, plus any future IAPs.

So how is the money split in this new system?

• 3% Payment Provider (always Apple in this first phase)
• 7% Apple (covers platform/review/distribution costs)
• 0-20% App Store or Store Front

The 0-20% for the Store Front is variable and is set in a new section of App Store Connect. App owners will have to authorize whether a specific Store Front is authorized to sell their app(s) and for what % range. A Store Front can use the commission % to compete with other Store Fronts. A range can be set for each store to allow for deals like a featured listing earning the store 10% while a standard listing nets 5% or something similar. Apple should also implement a range and earn a higher percentage for featured listings over a search result. Of course, an app owner can also elect not to have their app listed in the App Store if they choose.

Regardless of which Store Front makes the sale, Apple will process the payment and will split the proceeds from the sale according to the agreed %'s. Apple pays out commissions to the Store Fronts similarly to how they currently pay developers.

So what does all this accomplish?

It solves what I feel is the biggest anti-trust issue with Apple where they can prevent new innovative ideas from being explored.

It maintains all current security measures including user permissions, sandboxing, certificates, and a kill switch (including the problems associated with that).

It enables Apple to continue to earn 30% of sales they facilitate through the App Store.

Customers can still make purchases easily with a single Apple ID.

It allows third parties to create new innovative/curated Store Fronts and earn a commission for sales they facilitate, while still paying Apple a fair cut.

It allows developers to self-promote their apps and save on their commission costs, dropping it from 30% to 10% when their marketing creates the sale. This in turn can revitalize the decimated App Review sites since developers might actually be able to afford to buy online ads and sponsorships again.

What doesn't it do?

It doesn't solve the issue of free apps being able to use all the same development and distribution tools that Apple provides without contributing to those costs. For that, I'd like to see a per user, or per download (perhaps based on file size) cost that is paid by the developer of the free app. If it's $0.25/user for example, that should be a bearable cost (part of the marketing budget) for that company. But this needs to be explored in a whole other post.

It doesn't solve the issue of allowing alternate payment systems. As I stated earlier, this is a first stage. By separating out the payment provider and Apple platform commission %'s, I've opened the door to allow other payment systems later. The hard part is going to be managing the split of the proceeds if a different payment system is used. I also believe that if the payment % is dropped to 3% as I've done here, there's less of a reason to want to use an alternate payment system anyway. Except for the next point...

It doesn't solve the issue of developers not knowing who their customers are. Which an alternate payment system could help with. But if a developer really wants to know who their customer is, they can just ask in the app via an account system. If the user consents, they can supply their info. That feels like a fair way to handle it. Forcing a user to disclose their real identity just isn't cool in today's world.

Bonus notes:

1. One implementation detail to note: when a user buys an app from a Store Front, it would still show up in their normal 'Purchase History' where they can reinstall just as they can do now. It would list the name of the original Store Front, but they wouldn't need to go back into that app to reinstall since it would be possible that Store Front has closed.

2. I've written this with Apple in mind, but I believe the same system can and should be implemented by others in the industry, including the game console makers.

3. While Apple's % take will drop in some cases by implementing this system, I believe they'll actually make more money in the long term. Their devices will become even more powerful as new innovative apps are released for them. Fewer developers will be pushed toward making web and/or Android apps, or pushing customers to make their purchases outside of their apps.

4. I wonder if Apple feels, even if they want to reduce their fees, they have to fight this battle in court and be forced to make any changes in order to avoid being sued for breach of fiduciary responsibility to their shareholders? IANAL!

5. Everyone always cites the 30% number. But it's actually higher than that in a lot of cases. On top of the 30%, developers need to pay $100 USD annually for their developer account. They must buy Mac hardware because Apple's rules state all apps must be built on Apple branded hardware. But the biggest hit here are Search Ads. Developers often have to bid on their own app name and pay Apple extra $ just so their app comes up first in the search results when someone specifically searches for it. When Search Ads were first launched, I tried them out and all it did was drive my 30% fee up to 90+%.

6. I can't wait to see some of the really cool innovative apps that will come out. Even simple things like a third party phone dialer could lead to new ways of doing old things.

Addendums:

1. 2020/08/25 11:30am: Dave Murdock suggests Store Fronts would need to go through App Review as well. And yes, agreed, they're apps and so each update would be reviewed just like other apps. Further, I envision that in order to submit a Store Front, you'd need to be approved with a new type of developer account with it's own agreements, and most likely an additional fee, similar to Enterprise Developer Accounts.

We're hours away from the 2020 WWDC Keynote. Over the last week there have been tonnes of conversations about Apple's policies and while I'm on the side of change, this post isn't about that.

I've been compiling this list of security features that iOS needs for probably more than 5 years now, and every year around WWDC time I plan to publish it, and never actually get to it. Today, that's changing.

Here's my list of security features I'd love to see in iOS sooner rather than later.

1. Increased user control over device locking

There are multiple features that need to be added here.

a) A system level method that allows the user to lock the device underneath the currently open app. This means, keep the current app open and accessible, but the rest of the device is locked. You can't swipe to another app, you can't go back to the home screen, you can't tap on a notification and have it switch apps, in fact, if you have content in notifications hidden while the device is locked, incoming notifications in this mode would also be hidden.

Why add this feature? Because many apps used today require the app to be open for an extended period of time, so using those apps increases the risk for the user.

Examples:

Games (Pokemon Go): You need to keep your device open while you're walking around looking for Pokemon. If someone jumps you and steals your phone, it's unlocked and they have full access, just because you were playing a game. Of course, other games require you to keep the phone on because you're actively using the screen.

Sleep Trackers: There are apps that you leave open and running next to your bed while you sleep. They listen for your movements, snoring etc, to track your sleep. Doing this however leaves your phone unlocked and exposed for hours at a time while you're asleep. Ignoring people in your home that may exploit this situation, there's always the possibility of a thief (or even law enforcement) breaking in.

Video apps (Netflix etc): Want to watch the latest movie on your phone? That will keep your device unlocked for around 2 hours. Same risks apply, you could fall asleep, have someone grab the phone out of your hands etc.

Grocery Lists: In the age of COVID when we're all wearing face masks whenever we leave our homes, unlocking your phone becomes extra tedious. It's not unusual to disable phone locking while grocery shopping so you can constantly refer to your list without entering your passcode hundreds of times.

COVID Bluetooth trackers: Since Apple has blocked background Bluetooth access, several companies are releasing COVID Contact Tracing apps that use Bluetooth, but require the app to run in the foreground. Again, a serious security risk.

Allowing the user to lock the device underneath the current app solves these problems. The user can keep using the app in question, without risking the security of the rest of the device. This can be done with a gesture each time to trigger that you want to lock the device, or it could even use a timer that just auto locks the device under any app that is in the foreground for a specified time.

b) Allow a user to specify certain apps that can be used even if the device is locked. The UI for this feature would likely add those app icons to the lock screen so you can just jump right into them, locked or not. Same cases above are solved.

c) Use the Apple Watch to automatically lock your phone. If your phone moves too far away from your watch, auto-lock it. This handles cases where someone grabs the phone from your hand, and also cases where you leave the phone at your desk when you go to the washroom or something (back in the days when people went to offices). A bonus would be if you could disable Touch/Face ID via your watch.

If I can only have one of these security improvements this year, please let it be this one.

2. Improve the 2FA used on our Apple accounts

Apple's 2FA is one of the worst available. It's only better than systems that still use SMS for the second factor.

Ideally they allow you to store the key so you can use any standard 2FA app. At a minimum, they need to fix the geo-location on alerts. Telling me someone 150 kms away is trying to log into my account when it's really me on another device right next to me is pretty pointless. At least show me the IP address that is being used, and if it happens to be the same IP as the device you're showing me the alert on, tell me that too.

3. Secure the password dialog boxes used for our Apple accounts

The system can ask you for your iTunes/iCloud credentials at any time. This can happen while you're in the settings, the App Store, or even a random third party app. And the dialog is a standard dialog that any app can present. Most users use the same email address for their Apple ID as they do to log into apps, web sites, etc. This allows for unscrupulous apps to phish the user and trick them into giving up their vital Apple account password.

It is possible for advanced users to distinguish the difference between a dialog Apple is presenting and one presented by an app (swiping up on a system dialog is disabled), but try explaining that to normal users, never mind actually expecting them to test every time they're presented with a password request.

A simple solution would be to have a uniquely customized dialog box when the system is asking for your credentials. This unique dialog would not only include the email address of the account in question, but would display a secret image or pattern that was pre-selected by the user when they created their Apple account. This would need to be added to existing accounts during their next upgrade process.

4. Multiple users (including a guest account) on iOS

This is a simple one, and pretty self explanatory. Often someone wants to 'just borrow your phone for a sec'. A guest account with access to non-sensitive apps would make it easier and less risky to help someone out.

5. Improvements to Touch/Face ID

Add other options to the "Require Passcode" other than 'Immediately' when using Touch or Face ID. I've been asking for this change since Touch ID debuted, mainly because when debugging in Xcode, it's really annoying having to constantly unlock the phone while you're trying to install the newest build. You'd unlock the phone, build & run, then the phone would lock before the build started and you'd have to unlock it again.

With COVID, this is an important feature for people that aren't developers. See above for the grocery list scenario. When wearing your mask, being able to enter your password only once every 5-15 minutes would be a huge benefit.

6. Atomic app upgrades

When apps upgrade, it should be an atomic process. I've seen cases where app A is installed and working, then it upgrades via the App Store, but the network drops during the upgrade process. The app becomes unusable now. You can no longer access the data until the system completes the upgrade process.

Granted, listing this as a security fix is a bit of a stretch. But one of the times I saw it happen, it was 1Password that became unusable. I consider not having access to my passwords a security issue.

7. Medical ID

Users should be able to add photos to their Medical ID profile. This could include QR codes, scans of their hospital cards, insurance information, scans of medical history, prescriptions etc.

Acknowledgements:

My thanks to Markus Winkler at Unsplash for providing the photo used as the sample security image in the updated password dialog box.

Over-the-Air (OTA) app distribution is one of the methods Apple provides that allows you and your users to securely install iOS apps on devices. Other methods you've most likely seen and used are directly installing the app via Xcode on a device in your possession, TestFlight (Apple's beta distribution system), and of course via the App Store.

Each of these methods has their purpose.

• Direct via Xcode: Debugging and initial testing
• TestFlight: Beta testing
• App Store: Distribution to customers

So when is the OTA method needed?

Not every app can be distributed via the App Store: In-house apps for your staff, apps that Apple may not approve, or custom apps for your business customers that need to be distributed via Apple's private B2B store.

If the app you're building can't be distributed via the App Store, you're unable to use TestFlight for beta distribution either. OTA is a great way to distribute beta versions, and/or release builds for these apps.

Should you use OTA to distribute your apps?

Most likely, no. If you can use TestFlight and the App Store, use those. If you're building enterprise apps, or have a very early build that you can't get approved for TestFlight distribution yet, then OTA may be for you.

Why use OTAgo?

Setting up an OTA distribution system isn't very difficult. When you use Xcode to build your .ipa file, it gives you an option to create a manifest.plist file that's required for OTA distribution. You can basically drop that manifest.plist and your .ipa on your web site and set up the appropriate links. However, doing it this way, doesn't give you any protection and anyone that finds the link can install your app.

You can put the link behind basic authentication using Apache's .htaccess, or similar via nginx. But since iOS 13, using basic authentication requires the user to enter their credentials 3 times each time they install a build.

See @GeekAndDad's tweet here:

In Old Days™ hosting Ad Hoc build on http server in Basic Auth protected folder then involved 1 pwd entry in iOS Safari to install app.

In iOS 13 it’s now THREE pwd prompts (1 in Safari and 2 in the install process somewhere).

Know how to self-host w/ apache that works better?

— Dad (@GeekAndDad) January 18, 2020

You might be thinking, let's just use an obscure link no one will find, and we'll rely on security by obscurity. This of course is never a good plan, with search engines and malicious web spiders, your hidden link is unlikely to stay hidden.

On top of that, Apple has a new requirement that's coming into play in 'Spring 2020'. Due to rampant abuse of Enterprise accounts being used to distribute apps outside of the App Store, Apple is cracking down and now asking developers using an Enterprise profile how and where the app will be distributed. They're requiring developers to use a secure authentication method. This means either username/passwords or a restricted network accessible only via VPN/Intranet. See a screenshot of the current settings (note you'll only see this in your developer account if you're using an Enterprise account):

OTAgo handles the secure authentication for you, and it does it in a way that works around the requirement to enter a username/password 3 times. I've designed it in a way that it should be easy to set up and configure. The initial version includes a `simpleAuth` mechanism that lets you authorize users as simply as providing a list of username/password pairs.

I've also made the authentication system pluggable, so if you want or need to link into an existing authentication mechanism, you can do so by adding in your own plugin. If OTAgo proves to be useful/popular, I'll likely add some additional authentication methods, OAuth, MySQL/MariaDB etc. Of course feel free to send pull requests with additional ones. :)

You can check out the project here: https://github.com/DaveWoodCom/OTAgo. Let me know what you think. If you find it useful, please star it on GitHub!

Acknowledgements:

My thanks to Freepik at flaticon.com for providing the koala used in the OTAgo logo.

Also thanks to Paweł Czerwiński on Unsplash for the background of the banner above.

In a hurry, read the TLDR version below...

Quick summary of the problems I've been experiencing, in case you hadn't seen me ranting on Twitter...

1) Since upgrading to Catalina, I've been unable to complete a single Time Machine backup. Time Machine would continually try to backup, but after days or even weeks, it would eventually fail and I'd have to start it over.

At first I was using an existing Time Machine backup from Mojave. After that failed a few times, I decided to wipe it and start from scratch. Even after starting from scratch, the Time Machine backup would still take forever and then eventually fail. I joked on Twitter... that I was going to post screenshot updates each day showing the progress, but that it would end up being a 6+ month project.

Instead, I filed a FuBAr¹ (FeedBack Assistant/radar) and sent Apple some sysdiagnostic and tmdiagnostic files.

2) The second problem I was complaining about was due to my continuously filling SSD that wouldn't give up space no matter how much I deleted from it.

Of course, I was blaming APFS and Time Machine for this, since it's well known now that APFS snapshots are used to keep data available until Time Machine can back it up. I've been using tmutils to delete these snapshots when I needed to free up space, but even after deleting the snapshots, I wasn't getting my free space back².

I received feedback from my report I'd sent to Apple (Yay, they do work!). They pointed out that the issue was due to a third party app I have installed called Disk Drill by CleverFiles (which I have as part of my Setapp subscription). The app has a "feature" called Guaranteed Recovery that is supposed to help recover files later if you accidentally delete them. It "works" by creating thousands of hard links to what appears to be every file on your system in a hidden directory (/System/Volumes/Data/.cleverfiles/). This means when you delete a file, it's not really deleted because there's a hard link effectively creating a duplicate in the hidden folder. Personally I feel this is a terrible feature since you should have proper backups of your data anyway, so when you delete a file, it should be deleted. (Note: I originally installed Disk Drill in order to attempt to recover images from an SD Card that died, and so had no idea it was doing anything wonky to my main drives).

Over the last month or so, I've been trying to free up space on my main SSD because the OS is constantly complaining that my drive is full. Because I kept getting alerts that I needed more free space, I kept moving/deleting files. Eventually I'd cleared/off-loaded over 500G of data and was still scraping by with about 30G of free space. Now that I'm aware of the issue, I've taken a look into the .cleverfiles hidden folder on my iMac and I see it has over 450G in it. Wow.

First thing, add /System/Volumes/Data/.cleverfiles/ to the Time Machine exception list. This should fix the first issue with Time Machine taking forever to backup. Though, if you are using an existing Time Machine backup, it can still take a long long time for the next backup. My MBP has been working on it's first backup since I added the exception for 2 days still, and it's completed 150G of 177G. I created a brand new backup on my iMac and it completed it's first 650G backup in a day, so I'd recommend just wiping your old Time Machine backup and starting fresh (unless there's something you really need in the old backup, but then, why not restore it first, then wipe etc). Wait until after you read the rest of this post before staring a new backup though.

Next, I went into Disk Drill to disable to the Guaranteed Recovery feature. I don't need it, and think it's a flawed idea. While looking at how to disable it, I see it has a setting for how big the "Guaranteed Recovery Storage" should be. It's set to 8GB by default. Recall my .cleverfiles stats it has >450G. A lot more than 8G. That limit is supposed to be the limit of files hard linked but deleted. But it appears there's a bug in the app because it hasn't been trimming down to the 8G limit (perhaps there's a Catalina issue Disk Drill is hitting that prevents the trimming, and that's why this only started getting really out of hand after I upgraded). I didn't bother digging into this since I'm disabling the feature anyway. After disabling the feature, and "resetting" the storage, I expected the .cleverfiles folder to be removed or at least cleared. It was neither. Perhaps another issue due to Catalina. (Note that Disk Drill does have Full Disk Access permissions on my machine).

I went back into Disk Drill, and it had re-enabled Guaranteed Recovery on each of the drives I had just disabled it on. Another bug? Not sure, no time to dig into it, so instead, I uninstalled the app from my machines. Note that you can't just delete the app, you need to follow the full uninstall instructions here (modified slightly if you have the Setapp version): https://www.cleverfiles.com/help/how-to-uninstall-disk-drill/

I then manually deleted the /System/Volumes/Data/.cleverfiles/ folder.

One issue is that I can't remove a folder: /Library/StagedExtensions/Library/Application Support/CleverFiles due to it being read-only in Catalina. I supposed I could turn off SIP and delete it then, but I try not to do things normal users won't/can't do in order to keep my system consistent for testing.

After deleting .cleverfiles, finishing a full Time Machine backup, and ensuring there are no remaining APFS snapshots, I now have 593G free! Subsequent Time Machine backups are completing quickly again, and I expect my whole machine will start behaving better again (time will tell).

My thanks go out to Apple staff who responded to my report and helped restore (some of) my sanity! Hopefully the developers at CleverFiles can fix the issues they have in Disk Drill.

TLDR: It wasn't Apple's fault. A third party app, Disk Drill by CleverFiles was causing the issue. It was also causing the issue that prevented hard drive space freeing up as I deleted files. The apps not so clever feature was creating hidden hard links to basically every file on the system so you could recover it later in the odd chance you accidentally deleted a file.↩︎

Footnotes:

1: I'm still trying to make this nickname for the new Feedback Assistant reports stick, but I'm probably the only one. 🤪↩︎

2: I had used Daisy Disk to try and locate the missing disk space, but it didn't help find them. It did have a huge chunk (4-500G) marked as hidden, but didn't break down the location.↩︎

Abbey Jackson messaged me on Twitter:

I started to reply with a tweet, then figured it would take a few tweets so started a thread, then realized this needed to be a full blog post...

First, note I'm not a truck guy. I'm an SUV guy. But I appreciate how useful a truck can be when needed (I've borrowed my bro-in-law's F150 on more than one occasion). The Cybertruck looks like it will feel more like an SUV than a truck, and actually, I could see it shipping with an SUV option at some point.

Stainless steel is awesome. I've always wanted a DeLorean even thought about electrifying one as a side project at some point. The strong panels are a major bonus. My Bolt was dented when ice slid off my house and hit the hood during last spring's thaw. Over $1000 in damage. Also, I'm paranoid about a-holes keying Teslas. Granted there's a low probability of it happening, but I figure if it'll happen to anyone, it'll happen to me (I'm just that lucky).

The transparent steel windows look great (regardless of them failing during the demo). Making it harder for thieves to smash and grab will be a benefit since Telsas are often targets. Impressive to see a company actually use transparent metal too, it shows they're reconsidering everything, even if it's already "a solved problem".

Then of course, there's the non-tech aspects. I'll admit I've always liked the Hummer. But their gas guzzling nature of course has always prevented me from really looking at getting one. It might just be me, but drivers of Hummers and similar vehicles always seem to give the impression they just don't care about the world, and almost take pleasure in actively hurting it. Almost like they're shouting: "Look at me, obnoxious as hell, f*king up the planet!". Driving the Cybertruck feels like it'll be similar to me shouting: "Look at me, obnoxious as you, but helping the planet!"

I'm always trying to convince others to go electric when purchasing their next new vehicle. But everyone always has an excuse about why they have to stay with gas, and driving the Cybertruck will be proof that most of their "reasonable" excuses just aren't valid anymore (and I'll be able to take them for a ride to demo why):

While I don't "need" a truck, and I'd prefer an SUV, I already have a Bolt (considered getting a second but I think I'd rather diversify), and while I'd love a Model X, I'm an indie² app developer in a market where people don't want to pay for apps so I can't justify the cost of an X. The pricing on the Cybertruck is amazing. The dual motor Cybertruck is just over half the cost of the lowest end X. $49,900 vs $84,990 (USD for consistency).

Elon tweeted that a pressurized version of Cybertruck will be used on Mars. I’m not sure if people think he was serious or joking, but I can see it as a real possibility. How cool would it be to drive a Martian truck?

Now, will I actually buy a Cybertruck in late 2021 when they go into production? Which likely means it won't really be available until 2022 (in Canada). That's 2-3 years from now. I actually need a second EV soon since my wife's ICE car is nearing death. We're stretching it out as long as possible, waiting for either the Model Y or the Rivian R1S to ship (to Canada of course). Who knows what my situation will be in 2-3 years when the Cybertruck ships. Maybe one of my apps will take off and I can buy an X. Maybe I'll be working at Apple, Tesla or Rivian (call me 😁). Or maybe I'll be completely happy with whatever I buy in 2020. If stars align and it makes sense, then yes, I'll buy a Cybertruck once it's available. If it was shipping today, it would be on my driveway already. It's not, so the reservation will have to do. The fully refundable deposit is only $150. Compared to the $1000 deposit for the Model 3, this one is chump change. Worst case, it's an interest free loan I'm giving Telsa for a couple of years. Best case, it gets me to the front of the line when they do ship.

Update: just had an interesting interaction that might expose Elon’s hidden genius with Cybertruck. I had a conversation with a gas driver today, someone who has always resisted electrics. I showed them the Cybertruck which they hated the look of, but then they said: "did you see the electric Mustang just announced, I’d rather get that...". Suddenly the question became which electric vehicle to get, not electric vs gas. That’s a serious win!

Footnotes:

1: At some point, we're going to have to pay to remove CO² from the air. This is a cost that will have to be paid by our governments, and everyone just ignores it and treats it as not their problem. This is especially funny (annoying) because I ran a disguised poll on Twitter asking if someone would pay extra if they caused the damage or just let the everyone else pay, and 92% said they'd pay the extra. But they never do in real life.↩︎

2: I'm also working full time for a big company again, but I'm still indie at heart. ↩︎