Lead service · After release
Application Management for Apps Already in Use
A common belief is that a finished application stays finished. It does not. The platforms, stores and libraries around it keep changing whether or not anyone touches the code. Zevora Enterprise keeps published applications building, releasable and safe to use, including the business applications it publishes itself.
The problem
An Untouched App Still Changes Underneath You
None of the following needs a single line of your code to change. Each one can still take an application out of service.
| What changes | Left alone | Our handling |
|---|---|---|
| A new phone or desktop operating system | Screens render oddly, permissions behave differently, and the build tools eventually refuse to target it. | We test against the preview builds and aim to have a compatible release ready as people start upgrading. |
| An app store revises its rules | The next update is rejected, or the existing listing gets a warning with a deadline attached. | We read the change notices, adjust disclosures and target levels, and plan the work ahead of the deadline. |
| A library turns out to have a security flaw | The app ships known weaknesses to every device it reaches, and nothing outward looks wrong. | We track advisories for the libraries in use and patch, test and release on a priority basis. |
| An outside service retires an interface | Payments, maps, sign-in or messages stop working on a date someone else chose. | We note announced retirement dates and move the integration across while the old one still runs. |
| Certificates and keys expire | Push messages stop, web traffic shows a browser warning, or a signed build can no longer be produced. | We keep a dated register of what expires and where its renewal lives, and renew ahead of time. |
| A crash pattern appears after a device update | Reviews mention it before anyone on the business side does, and the cause gets harder to trace. | We read the crash and diagnostics reports, reproduce the fault and decide whether it waits or ships now. |
Inherited code is welcome, read first. If someone else built the application, we go through the repository, the build setup and the release history before agreeing to look after it, and tell you what we found.
Ownership
The Owner of an App Answers for It, Not the Maintainer
ZEVORA ENTERPRISE manages applications in two different capacities, and they carry different responsibilities.
Applications we publish ourselves
ZEVORA ENTERPRISE owns these, provides them to their users and carries the responsibility for them. Keeping them running is part of publishing them.
Applications a client owns
The client remains the owner and the end provider to its users. We carry out the management work agreed with that client, and nothing in that work transfers the product to us.
ZEVORA ENTERPRISE handles two kinds of application: its own, and those owned by clients.
Responsibility for an application ZEVORA ENTERPRISE owns lies with ZEVORA ENTERPRISE alone.
A client who hires ZEVORA ENTERPRISE for development, management or advertising work keeps ownership of the product, and only a signed written agreement could change that.
Scope
Management Covers Upkeep. It Stops Short of a Rebuild.
Where the line sits is written into each agreement. This is where it usually falls.
Covered
- Compatibility work for new operating system versions
- Keeping store listings within current policy
- Library and framework updates, security fixes first
- Investigating and fixing reported defects
- Preparing, signing and staging releases
- Reviewing crash and diagnostics reports
- Watching launch time, memory and battery cost
- A written plan for upcoming versions
Not covered
- New features beyond what was agreed. Those are scoped and estimated as a separate piece of work.
- A promise that a store will approve an update. The store decides, and we prepare the submission as well as we can.
- Answering the app's own users, unless a written agreement says otherwise.
- Taking over a client's developer account. It stays registered to the client, and we work inside it with the access we are given.
A made-up example
A Quiet App Tends to Break All at Once
An illustration only, not an account of any real application.
Say an ordering app went out a couple of years ago and the project has not been opened since. A new operating system arrives. The store now asks for a higher target version. One library in the project has a published flaw.
Any one of those is routine. Together they mean the build no longer compiles, the tools have moved on, and a simple fix now needs a round of upgrades before it can even start.
Managed instead
The same app gets small, regular upgrades. Each one is easy to test, and the project stays one step from a release rather than several.
When something breaks
Every Reported Fault Goes Through the Same Checks
Planned versions follow a calendar. Faults do not, so each one is sorted the same way before anyone starts typing.
- 01
Reproduce it
A fault we cannot make happen on purpose is a fault we cannot prove we fixed. Device, version and steps come first.
- 02
Decide if it waits
Data loss, security exposure or a broken payment ships as soon as it is ready. A cosmetic glitch joins the next planned version.
- 03
Fix it in the open
The change goes through version control and review like any other code. Nothing is edited directly on a live server.
- 04
Release in stages
Where the store allows it, the update reaches a small share of users first, so a bad release can be halted before everyone has it.
- 05
Write it down
A short changelog entry records what broke, why, and what changed. The next person to work on the app inherits the reasoning.
Start here
Send Us the Repository Before It Needs Rescuing
Tell us what the application does, where it is published and when it last had an update. We will read the code, list what is out of date and suggest a sensible order for dealing with it.