The domain lock process was an absolute fiasco at our company. I think this could work if you did this at the time your company launched, but the moment you have employees who have Apple IDs tied to their work email that aren't from the Business Essentials system you are stuck in an impossible-to-mange place.
There are several cheap MDM solutions for Apple devices that I would rather pay for than be dependent on this. (We've used SimpleMDM and love them.)
I'm currently in that hellish process too... I don't know how to get out of it. Did you know that your employees will be forbidden from downloading from the App store once you launched that migration? It's a nightmare
Apple and MDM has always been a shit show. In the days as recently as Ventura (last time I tried it), MDM bypass was as simple as "null route 4 DNS entries during install process, remove null routing after install complete, and never be bothered by it again". This is on Apple Silicon. With no workarounds or anything, upgrades work all the way up to Tahoe.
Like really Apple, that's your device "locking"? I could test activate my work Mac with my personal Apple ID while doing this, no alarm bells, nothing, effectively "It's your laptop now".
MacOS used to be excellent for a short period of time when Fleetsmith existed. Then Apple purchased Fleetsmith around 2020 and killed the product not long after.
Fortunately around the same time, JamF ended the practice of the mandatory Jamf JumpStart (£5K fee), which finally made Jamf a feasible option for the company I was in at the time.
Of course there is a kill switch. This is one of the key features of an MDM/endpoint manager. You won't be able to sell one without it. It's also built in to apple's management protocol (which most endpoint management systems leverage) and in activesync.
You just have to secure it properly. Have limits to how many one admin can wipe etc. But trust me every company with managed IT assets has this capability. Often even in BOYD scenarios! Stryker just failed to secure access to it properly and to set sensible limits.
However, the feature isn't very effective in the field. It's very unlikely for an attacker to be smart enough to bypass the password on a stolen Mac which is needed to connect it to WiFi, yet at the same time be dumb enough to connect it to the unfiltered internet so it can receive the wipe command. The overlap between these sets of people is almost zero. We do fire a wipe at every stolen computer but I doubt it ever actually happens. If it ever happens it'll be a total end user fail (like writing the password on a post-it with the laptop)
Either you will lose it to a common thief who won't be able to breach the login (99% of cases), or to a really targeted adversary who has cellebrite or something similar and won't connect it to the internet ever again. This is still the most risky scenario because if someone like that steals it, there's bound to be something really valuable on it.
In practice this is something more suited to mobile devices.
It can be done that way, but it is definitely not the norm. Businesses will generally “purchase” (many for €0) apps in ABM that are to be used for business purposes and push those to devices, the user can then use an Apple ID to download any other apps they want for personal use.
If they’re using Managed Apple IDs they will have no access at all to the app store and won’t be able to download their own apps anymore. IT department will have to buy and assign any apps that anyone needs, even the $0 ones that only 1 person needs.
Yep. Truly horrid policy. Where I work our issued iPhones suck to use without App Store access; no Bitwarden was the killer for me personally. Everyone I checked with uses their personal email/Apple ID instead of the MAID, and there's a sword over your head if you ever accidently copy/paste something from internal emails to something like Notes which has iCloud sync (we're semi serious about leaker). Absolute failure of an MDM setup by Apple.
MDM can restrict pasteboard from managed apps to non-managed apps, as well as allowing iCloud sign-ins but restricting which iCloud services are allowed.
It's an absolute failure of the MDM server administrator for allowing such things, not on Apple.
I haven’t. Did have issued laptops that were company managed but I basically didn’t use and, in any case, I like many others reinstalled a clean operating system image and did my own support.
At most decent sized companies with a cyber security and network admin team, this is probably the fastest way to get disconnected from the internal corporate network with no way to reconnect.
I always seem to end up with local admin at the bigger places I've been at because I'm so annoying with onboarding and requesting access to download development tools.
I was talking about domain capture. If you own my apple ID just because I used the company email to register it, I will definitely consider sueing you.
Just on a personal note, tying your personal devices to your work email account is a very silly thing to do. Even if it's your company you could be locked out of your company email account at any time (HR grievance, SEC investigation, hostile takeover...) Losing access to your devices and not being able to access things like reset emails at the same time would not be fun.
This was a big pain in the ass for me to figure out. I ended up using the free version of Mosyle and hiring someone on Fiverr to help me figure out how to get the licenses assigned to our managed devices.
I did not. If I had known what would happen when we tried this we would have skipped the process entirely. Our staff (roughly 125) was so confused and it wasted a lot of time communicating about it, then trying to roll it back, etc.
The Domain Capture process cannot be canceled once it’s started. It’s also not required, unless by your company policy.
The point is to make sure there’s not a mess on the other end when you enforce SSO for MAIDs.
Apple’s documentation for ABM and ABE is atrocious, but they do manage to document a bunch of footguns, just poorly and in seemingly bizarre places.
For example, ABE doesn’t support MDM migration (either as source or destination), despite the fact that the feature launched with macOS/iOS/iPadOS 26 and is supported by other MDM solutions.
And you cannot push custom config profiles with ABE which declare a non-Apple preference domain. Utter nonsense.
If you’re using the full ABM-with-ADE and MDM stack, it’s expected that you push apps to employees.
You can also use Munki to make apps available to users. You can just push only Munki via MDM if you want, and let it manage app installs and self service installs for you. There are caveats.
> I think this could work if you did this at the time your company launched, but the moment you have employees who have Apple IDs tied to their work email that aren't from the Business Essentials system you are stuck in an impossible-to-mange place.
I had the same thing happen but with Microsoft. A friend and I had started a small consulting business and were using Google Workspace, but I needed a Microsoft account to interact with a client. I made one with my business email. None of us knew any better, but I couldn’t connect with our client’s Microsoft setup because it was a personal account. So I went to set up a business account. It was a whole fiasco and the only way I could really fix it was create an alias and use that for Microsoft.
That's why Enterprise vendors try so hard to get startups using their stuff. Lock-in is so strong. I can't imagine having a working system at a 100 person company and then trying to migrate to something else unless the current situation was truly awful.
> the moment you have employees who have Apple IDs tied to their work email that aren't from the Business Essentials system you are stuck in an impossible-to-mange place
So give all the employees an email alias they can use to create a new Apple ID for this purpose?
> I think this could work if you did this at the time your company launched
This should not be a surprise. Greenfield services have not existed long enough to resolve edge cases that inevitably arise while integrating existing operating models already in use.
My point was trying to fit a new company with no barnacles into an existing process model will always be easier than retrofitting an existing company model full of edge cases the service never had to engineer around
Not really sure why you made that point only to wave it away later saying it's always been broken regardless
Employee needs to download Microsoft Remote Desktop (sorry, Windows App) that is only distributed through App Store.
Employee does not trust the company having access to everything else in their personal iCloud account - photos, mails, messages, calendar, reminders, etc.
Employee registers a new Apple ID with company email, as it would be only used for downloading one single app.
I think the idea is that it happens before they lock the domain as a business. Before that, if you have an email address you can create a personal account with it.
We've been very happy with Northflank's blend of ease-of-use with configurability when you want it. (We're running BYOC AWS.) Running several workloads and it's the best preview-environment-per-PR setup I've encountered across PaaS options.
The scoreboard running all the way around the circumference of the cup was awesome. My dad worked in RI for a few years as a kid and we went to a bunch of games at McCoy. I didn't realize until I was older how many long-time big leaguers appeared in that game!
This is really a huge bummer. It was a fantastic service and made it easy to run a "two-person approval" system on all kinds of access and infra changes without building something blocking or bureaucratic.
We moved off of Heroku in late-May/early-June of this year. It took a few weeks of half-time work for one person to make everything happen. We were already using Docker in CI, so we didn't need to spend much time making our app work in Docker for production. We paid the $500 for Porter's "white glove" migration service because we figured it would be useful to be able to get quick feedback about choices and changes.
We had some AWS experience from running our backing services (RDS, Elasticsearch, Memcached, Redis) on AWS despite doing compute on Heroku for a long time, but we'd never done EC2 or EKS for deployments on AWS. Despite having been on Porter now for months, I'd say we still don't know or really need to know a ton about k8s, but we are familiar with some basics around pod sizing, healthchecks, deployments, etc.
I think Porter does a lot to put themselves out as as destination for people leaving Heroku. I'm not sure if this would have been more work to do something like Render, but I was very pleased with the timeframe, hours spent, and the ease of cutting over.
We have a monolith that handles ~50k/min traffic at peak use as well as a couple very tiny services that do some accessory stuff. All the apps are Rails apps.
One of the reasons that we chose Porter over other options is that we really liked their setup for Preview Environments, which are an important part of our workflow here. The experience of running preview apps on Porter is notably better than on Heroku, where we started to see a lot of unreliable behavior on app launch that resulted in the app being unusable and the only fix was to close and open a new PR .
On the whole this was a really positive experience for us. We're seeing better performance, we're paying less (in Porter + AWS compute combined) than we did for Heroku Enterprise, and our ability to deploy mid-day when we're under load is better than it was before. I've spent most of my 12 years or so of Rails development working on Heroku (and we had been on Heroku for almost six years), so we had some fear around moving to unfamiliar tooling, but this has been a big win for us.
CommonLit is a 501(c)3 non-profit whose mission is to improve the educational and economic outcomes of students through better literacy and critical thinking skills. Our non-profit's application supports millions of students in the United States and around the world with a rigorous, high-interest literacy curriculum in English & Spanish.
Our small (nine-member) engineering team works in a collaborative, high-trust environment where we ship high-quality software to power CommonLit's curriculum and to assist teachers in assessing their students growth. As a Senior Engineer you'll lead significant technical projects, contribute your own code, review teammates' work, and advance CommonLit's mission. You'll act as a force-multiplier for your teammates' work in addition to your own high-leverage contributions.
Our team is a group of life-long learners. We value sharing new ideas, lifting each other up, and building performant, reliable software that teachers can rely on in the high-stress classroom environment.
Responsibilities:
As a Senior Software Engineer your work will include:
* Writing high-quality Ruby and Typescript code and tests for our Rails monolith
* Reviewing your teammates' work in our code review workflow
* Researching technical ideas for upcoming projects
* Mentoring and helping level-up less experienced engineers
* Deploying and operating our application
Qualifications:
* 5-8+ years of web development experience with some of that time spent on a Rails production application
* Experience working with a modern JavaScript framework (React, Vue, etc.)
* Ability to work comfortably in SQL (we use PostgreSQL & Redshift)
* Experience dealing with performance and scaling issues
* You have a commitment to improving equity of opportunity for students of color
I've been using Depfu for a while and I think it handles some of the biggest pain points with Dependency spam.
- Package releases don't get PRs in their first 24 hours unless they are for security issues, so you don't get noise if there's a yank or a quick patch for a bug in the latest release
- You can set development (or production!) packages to only update once a week
- Packages that are known to have a very frequent release cadence (AWS SDK subcomponents, looking at you)_get pushed to a much slower PR pace so that you only update them 2x/month, etc.
- This might be fixed now, but it had much nicer auto-merge behavior for releases that passed CI.
- With Yarn, it can run `yarn-deduplicate` after updates to trim down shared dependency bloat.
FWIW we still use Dependabot for security patches only because they seem to get picked up a few hours earlier. We also have much tighter lock rules on some JS packages which seem to make breaking changes on patch/minor releases.
`git push heroku main` doesn't work if your repository is large enough (not sure if this is raw file sizes or the Git data size). Some of our apps can't be redeployed using this method, we have to use the build workaround which has its own set of issues.
There are several cheap MDM solutions for Apple devices that I would rather pay for than be dependent on this. (We've used SimpleMDM and love them.)