Yeah been banging on about this for years. Nobody taking it seriously.
ADMINS DO NOT MANUALLY UPDATE APPS!
If you have already migrated your apps to Forge they are now locked in a terminal spiral where your customer base will trend toward 0% of installs ever running the latest version.
I built and deployed Forge apps on UI Kit 1 and watched as Atlassian deprecated that, changed permission scope requirements and even the naming of scopes. This forced multiple major version upgrades completely outside of my control. Those are zombie apps now with the majority of installs forever stuck on outdated versions. One future deprecation or scope change is all it takes, and we all painfully know how often deprecations occur on this platform.
Effectively the migration sets in motion the destruction of your existing customer base. You may fix bugs and deploy new features but over time (deprecations, scope changes, Connect EOS etc) those customers will just cancel the subscription if the end-users are always running outdated legacy versions. Admins don’t manually update but they do regularly cull apps with low usage to cut costs.
Nor have I seen any mention of what the plan is when the Connect platform is completely switched off. Most installs will still be running on Connect because admins won’t click the update button. Meanwhile Atlassian have said legally they can’t ever automatically click that button for admins. That incompatible bind will be a disaster. Admins never manually update + Atlassian can never automatically update. Is anyone thinking about this stuff?
Atlassian’s proposed “solution”: Rolling Releases. That’s still in EAP despite the fact that partners are already being unfairly hit with revenue penalties for not migrating. And the moment you do adopt rolling releases presumably that triggers a new major version which requires manual admin update - docs don’t make it explicit despite changing permissions section in manifest.
And the Forge team have stated that rolling releases is taking inspiration from the way iOS manages permission scopes. iOS works because it’s a 1:1 relationship between the developer and the individual user. Confluence/Jira apps are obviously 1:n where the org admin is the gatekeeper for whether n users install the latest version. Poor model to take inspiration from.
So the entire ecosystem is being forced to migrate to a new platform that hasn’t yet figured out how updates and versioning works. That should have been carefully designed and deployed on day one.
Ok not great, well has Atlassian implemented any sort of admin app update notification system? Nope, nothing. Are developers given any practical communication methods to contact those admins? Nope, nothing. The only path available is to plaster apps with warning messages or make outdated apps unusable for end-users, but those end-users have zero control over that app update process.
Imagine an iOS app stopped working on your phone and you had to go ask permission from someone you may not even know. That’s the model here. Will that user manage to both identify who the admin is AND convince them to update the app? Or will that user just stop using the app? I think they’ll just stop using it. And the next time the admin does a cost-cutting sweep they’ll identify low usage and uninstall that app. Scale this scenario to the entire Marketplace and it’s not going to end well.
In regards to this thread: yes, you’re going to need a 10,000 word textarea for partners to explain to customers why an app hasn’t yet migrated to Forge because Atlassian’s deadlines and messaging are inconsistent with the technical reality and readiness of the platform.