Last updated: 05/08/2026
There is a particular phone call that comes about eighteen months after launch. The app works, the business depends on it, and then something has to change: a new payment provider, an OS update, a rebrand, or simply a better price from another team. That is the moment a company finds out what it actually bought. Sometimes the answer is a repository, two store accounts and a signed assignment. Sometimes the answer is a login the vendor controls, a zip file nobody can build, and an app listed on the App Store under someone else’s name.
The difference between those two outcomes is not luck and it is not the size of the invoice. It is a handful of paragraphs in a contract, plus four or five administrative decisions made in the first week of the project — decisions that cost nothing at the time and are expensive or impossible to reverse later. This article sets out what a Singapore business should hold when a build ends, where the law puts ownership if the contract is silent, and the questions that separate a vendor who has thought about handover from one who has not.
The short answer
You own exactly what your contract says you own, and if the contract is silent, Singapore law does not hand ownership to the party that paid. Section 133 of the Copyright Act 2021 makes the author the first owner of copyright in an authorial work, and section 13 puts a computer program squarely inside that category as a literary work. A development studio is not your employee, so the employer rule in section 134 does not rescue you either. The Intellectual Property Office of Singapore states the position in plain business language: "In general, the person who created the work (i.e. the author) owns the copyright in the work", and that this "includes situations where the author was paid under an agreement (i.e. commissioned) to create the work".
Layered on top of copyright are two contracts you did not draft and cannot amend: the Apple Developer Program License Agreement and the Google Play developer terms. Those govern the store accounts, the listings, the reviews, the subscribers and the signing keys — and they bind whichever legal entity enrolled, not whichever company paid for the build. That is why app ownership has to be treated as three separate questions rather than one: who owns the intellectual property, who controls the accounts the app is published from, and who physically holds the artefacts needed to produce the next build.
Get all three right and switching vendors is an inconvenience measured in days. Get any one of them wrong and you are negotiating from a position where the other party can decline, delay, or price the handover however they like.
The five things you must hold at handover
At the end of a build there are five assets that together let you run the app without the people who made it. Anything less and you have a dependency rather than an asset. The table below is the list we would want a client to hold at the end of any project, together with where each one sits by default if nobody writes it down.
| Asset | Who holds it if the contract is silent | What to require | How to verify it is real |
|---|---|---|---|
| Copyright in the source code | The developer — Copyright Act 2021 s 133(1)(a) | A written assignment to your company, signed by the vendor | Read the executed document; check the assignee is your registered entity, not a person |
| The repository (code plus history) | Whoever created the repo account | Repository transferred into an organisation account you own | You can add and remove collaborators without asking anyone |
| Apple Developer Program account | Whoever completed enrolment becomes Account Holder | Enrolment under your company legal entity and D-U-N-S Number | Your seller name on the App Store listing is your company |
| Google Play developer account | The account owner, singular | An organisation account created with your own D-U-N-S Number | Play shows your legal name, address, email and phone |
| Build artefacts and secrets | The team that set up the build | Upload keys, certificates, environment config, third-party keys, design source files | A person outside the vendor can produce a signed build from a clean machine |
Default-ownership column reflects the statutory default in the Copyright Act 2021 and the platform documentation quoted in Sources. It is a summary for business readers, not legal advice on your specific contract.
Note what is not on that list: a PDF specification, a set of screenshots, or a login to an admin panel. Those are outputs of the project, not control of it. The test that matters is operational rather than documentary — can a competent third party take what you hold and ship version 2.1 to your users next Tuesday, without a single message to the original team. If the honest answer is no, you are holding deliverables and not an asset.
Your source code and the repository it lives in
Ask for the repository, not the code. A zip file of source code satisfies the letter of most handover clauses and almost none of their purpose: it arrives without commit history, without branches, without the issue trail that explains why a strange workaround exists, and frequently without the configuration that makes it compile. The unit that carries value is the repository — the code plus its history plus the access control around it.
Transferring one is a defined operation, not a favour. GitHub documents it directly: "When you transfer a repository to a new owner, they can immediately administer the repository’s contents, issues, pull requests, releases, projects, and settings". Two conditions in the same document are worth reading closely before you assume it will be simple. The first: "To transfer a repository you must have administrator access to the repository" — if your vendor gave you read access, you cannot initiate anything. The second is the one people miss: "The original owner of the repository is added as a collaborator on the transferred repository." A transfer does not evict the previous owner. Removing that collaborator is a separate deliberate act, and it belongs on your offboarding checklist next to revoking cloud console access.
Around the repository sit the things that make it buildable, and these are where handovers usually fail. Environment configuration and API keys for the services the app talks to. The upload key or keystore. Provisioning profiles and certificates. Design source files rather than exported PNGs. The content of any headless CMS. Analytics and crash-reporting projects. Push credentials. None of these are copyright questions; they are custody questions, and the only reliable test is the one described above: give the bundle to somebody who has never touched the project and see whether they can produce a signed build. Run that test while you are still paying the vendor, not after the relationship has ended. A handover clause that is exercised for the first time during a dispute is a clause nobody has ever tested.
One more item deserves its own line: documentation of the third-party components in the build. Every modern app is assembled partly from open-source libraries, each carrying its own licence conditions, and your new team inherits those conditions whether or not anyone lists them. Asking for a dependency inventory at handover costs the vendor an afternoon and saves your next team a week of archaeology.
Why the store accounts must be in your company name
Enrol the accounts yourself, in your own company name, before development finishes — because the platform rules make the enrolling party the controlling party, and undoing that later depends on the other side cooperating. Apple is explicit about who ends up in charge: "When you enroll in the Apple Developer Program or Apple Developer Enterprise Program, you automatically become the Account Holder for your membership", and the App Store Connect reference adds that the Account Holder "is the only user that can sign legal agreements, renew membership, request access to the App Store Connect API, remove auto-renewable subscriptions from sale, submit Safari Extensions, or create developer ID certificates". If your vendor enrolled, your vendor holds that role and everything attached to it.
Apple also states who is entitled to enrol an organisation in the first place. On the enrolment page: "As the person enrolling your organization in the Apple Developer Program, you will be the Account Holder and must have the legal authority to bind your organization to legal agreements". The same page requires that "Your organization must be a legal entity that can enter into contracts with Apple", refuses DBAs, trade names and branches, and notes that "Your organization’s name will be displayed as the seller name of your apps on the App Store" — so the entity on the account is visible to every customer who scrolls to the bottom of your listing. Company enrolment also needs a D-U-N-S Number "registered to their legal entity", which is precisely why a vendor cannot lend you theirs.
Google Play works differently in mechanics and identically in consequence. An organisation account requires a D-U-N-S Number: "This is a mandatory requirement when providing developer account information for your organization or business, and is used by Google Play to verify your identity." Google warns about the lead time as well — "This process can take up to 30 days so you should plan ahead. You will not be able to create a developer account for an organization without one" — which is the single best argument for starting account registration in week one rather than the week before submission. Google then publishes your identity to users: "To help improve transparency and user safety on Google Play, Google will display your legal name, legal address, developer email address, and developer phone number on Google Play."
The distinction that catches people out is between being given access and holding ownership. Play Console has "three different access levels ... account owner, admins, and users", and an admin invitation is revocable by the owner at any moment. Ownership moves only one way: "Only the account owner can transfer ownership of a developer account", and "The prospective owner must provide and verify identity information as part of the process." Being made an admin on your own app feels like control right up to the day it is withdrawn.
| Question | Apple Developer Program | Google Play |
|---|---|---|
| Who ends up in control | The person who completes enrolment becomes Account Holder; only one person holds the role | The account owner; admins and users are invited and revocable |
| Company identity requirement | Legal entity with a D-U-N-S Number registered to it; no DBAs, trade names or branches | Organisation account requires a D-U-N-S Number; can take up to 30 days to obtain |
| What the public sees | Organisation name shown as the seller name of your apps | Legal name, legal address, developer email and phone displayed on Google Play |
| Published fee | "Enrollment is 99 USD (or in local currency where available) per membership year" | "There is a US$25 one-time registration fee" |
| Moving an existing app | Per-app transfer between accounts; listing, ratings, reviews and Bundle ID are retained | App transfer between accounts; both accounts must be registered and active first |
| Moving the whole agreement | PLA s 14.3: no assignment "without Apple’s express prior written consent and any attempted assignment without such consent will be null and void" | Ownership transfer initiated only by the current account owner |
All cells quoted or summarised from the Apple and Google pages listed in Sources, retrieved 05/08/2026. Fees are the platforms published figures and are billed to whoever holds the account.
That last row deserves emphasis because it is the escape hatch people assume exists. The Apple Developer Program License Agreement states that the agreement "may not be assigned, nor may any of Your obligations under this Agreement be delegated, in whole or in part, by You by operation of law, merger, or any other means without Apple’s express prior written consent and any attempted assignment without such consent will be null and void". You cannot quietly hand a developer account from one company to another the way you might hand over a domain name. The documented route is a per-app transfer into an account you already hold — which is another reason the account has to exist on your side first.
There is a cost angle too, and it is small enough that no one should be trading control for it. Apple publishes enrolment at "99 USD (or in local currency where available) per membership year" and Google Play at a "US$25 one-time registration fee". Our own published pricing lists app store developer accounts, hosting and third-party service fees as billed at cost rather than bundled — which is the practical shape of an arrangement where the accounts sit with the client and the invoices simply pass through.
Signing keys: the part you cannot simply hand over
App signing is the one item on the handover list that cannot be solved by emailing a file, and understanding why turns a scary problem into a manageable one. On Android, Play App Signing means "Google manages and protects your app’s signing key on the same secure infrastructure that Google uses to store its own keys. These keys are protected by Google’s Key Management Service (KMS)." The key that ultimately signs what users install is not in anyone office safe — which is exactly why control of the Play Console account, rather than possession of a keystore file, is what determines who can ship an update.
Two keys are involved and the difference matters at handover. The upload key is the one your developers hold: "You use this key to sign your app bundle before uploading it to the Play Console. Google uses it to verify your identity. If compromised or lost, Google can reset this key for you." The app signing key is the durable one: "Google uses this key to sign the final APKs delivered to users’ devices. You can have Google generate this, or you can provide your own. This key cannot be reset if you manage it yourself (without Play App Signing) and lose it." Google also advises that "For maximum security, your upload key and app signing key should be different."
Read those two paragraphs together and the practical conclusion is unusually clean. A lost or withheld upload key is a recoverable inconvenience if you control the account. A signing key you manage yourself, held only by a vendor who has stopped answering email, is a catastrophe that can force a new listing and the loss of every install, review and ranking attached to the old one. On the Apple side the equivalent lever is the Account Holder role, since Apple states that only the Account Holder can "create developer ID certificates" and must accept updated agreements on behalf of the organisation. Certificates can be regenerated; the authority to regenerate them cannot, if it sits with someone else.
What Singapore copyright law gives you by default
By default, it gives you nothing beyond what you negotiated — and that is the correct starting assumption when you read any development contract. The Copyright Act 2021 sets the first-ownership rule in section 133: "the first owner of copyright in a work is — (a) in the case of an authorial work — subject to subsection (2), the author". Section 13 confirms that a computer program counts, defining a literary work to include "a compilation in any form" and "a computer program", and IPOS lists source code among literary works in its own introduction to copyright.
Two adjacent rules complete the picture. Section 134 gives copyright made "in the course of a contract of service" to the employer — useful if your own staff wrote part of the app, irrelevant to an external studio, which works under a contract for services rather than a contract of service. And the old commissioning rule that many people half-remember has been narrowed almost out of relevance: section 135 is headed "First owner — sound recordings, films and certain authorial works commissioned before 21 November 2021" and applies only where the parties "entered into an agreement ... before 21 November 2021", covering photographs, portraits, engravings, sound recordings and films. It never covered software, and for anything agreed since that date it does not apply at all.
What actually moves ownership is a written assignment. Section 137 provides that copyright may be transferred "as personal or moveable property by — (a) assignment; (b) testamentary disposition; or (c) operation of law", and section 138 sets the formality in nine words that every buyer should memorise: "An assignment of copyright is valid only if it is — (a) made in writing; and (b) signed by or on behalf of the assignor." Not implied by an invoice. Not implied by a proposal that says the work is "for" you. In writing, signed. IPOS gives the same advice in commercial terms: "We recommend having a written contract to document the assignment or licence."
One detail is easy to get wrong in a hurry. The assignee should be your company, not a founder personally. A company incorporated in Singapore is "a body corporate ... capable immediately of exercising all the functions of an incorporated company and of suing and being sued and having perpetual succession" under section 19(5) of the Companies Act 1967. Rights assigned to an individual do not automatically belong to the business, and that gap tends to surface at the worst possible moment: during due diligence, when a buyer or investor asks the company to prove it owns the product it is selling.
| Who wrote the code | Default first owner | Provision | What you need in writing |
|---|---|---|---|
| External studio or freelancer | The studio or freelancer | Copyright Act 2021 s 133(1)(a) | An assignment to your company, signed by the vendor |
| Your own employee, in the course of employment | Your company | Copyright Act 2021 s 134(3) | Nothing extra, but confirm the employment contract has no contrary term |
| Commissioned photo, film or sound recording, agreement before 21 Nov 2021 | The commissioner | Copyright Act 2021 s 135 | Applies only to pre-21 Nov 2021 agreements, and never to software |
| Anything commissioned on or after 21 Nov 2021 | The creator | Copyright Act 2021 s 133, subject to s 133(3) written agreement | A written agreement recording the contrary intention |
Section text read from Singapore Statutes Online on 05/08/2026 (current version markers: 21 Nov 2021, Act 22 of 2021). Summary for business readers; it is not legal advice, and a lawyer should review your actual agreement.
The contract clauses to check before you sign
Read four clauses before you read the price, because these are the ones that decide whether the price is the whole story. They are the IP assignment, the pre-existing and third-party materials clause, the handover obligation on termination, and the payment condition attached to the assignment. Each has a version that protects you and a version that reads reassuringly while protecting the other side.
| Clause | What good looks like | Worth questioning |
|---|---|---|
| IP assignment | Named assignee is your company; assigns copyright in the deliverables; signed by the vendor | "Client is granted a licence to use the software" — a licence is not ownership |
| Trigger for assignment | Assignment effective on payment of the final invoice, with the date defined | Assignment "on completion" with completion left undefined |
| Pre-existing and third-party material | Vendor’s internal framework licensed to you perpetually and irrevocably; open-source components listed | Silence — you may be assigned code you cannot legally run without a separate licence |
| Store accounts | Accounts enrolled in your legal entity from the start; vendor added as a user | Vendor publishes under its own account "for convenience" |
| Handover on termination | Defined list, defined deadline, applies however the contract ends | Handover only "upon mutual agreement", or only if the contract ends amicably |
| Data | Export of personal data in a usable format, plus deletion from vendor systems | No mention of what happens to user data after the relationship ends |
A buyer-side checklist drawn from the statutory and platform requirements cited in this article. Wording should be settled with your own legal adviser.
Tying assignment to final payment is normal and reasonable; leaving the trigger vague is not. If the clause says ownership passes "on completion of the project", ask what document records completion and who signs it. A project that is 98 per cent finished when a relationship sours can sit in that gap indefinitely, and the party holding the code has very little incentive to close it.
The pre-existing materials clause is the one that most often surprises buyers. Studios reuse internal libraries, and there is nothing wrong with that as long as the licence you receive is broad enough to keep operating: perpetual, irrevocable, and permitting modification by whoever maintains the app next. Without that, you can own the application code and still be unable to change part of it. The same logic applies to fonts, icon sets, stock photography and map or messaging services embedded in the product, all of which carry their own terms that follow the app rather than the vendor.
Finally, be specific about scope. "All intellectual property arising from this project" sounds comprehensive but leaves room for argument about design files, backend infrastructure, admin dashboards and content. Naming the deliverables — mobile application source code, server-side source code, design source files, documentation — takes one extra sentence and removes the ambiguity that arguments feed on. If you are still assembling the brief, the same discipline that produces a clear app brief makes these clauses much easier to write, because you already have a list of what is being delivered.
If a former vendor is holding your accounts today
Start by establishing exactly what you control, because the remedy differs completely depending on whether the problem is access or ownership. Sign in to each service and check your own role rather than what you were told: are you the Account Holder in App Store Connect or a user with limited permissions, are you the account owner in Play Console or an admin, do you have administrator access on the repository or read access. Write down the answers before you contact anyone. Negotiations of this kind go better when you already know which requests are one-click operations for the other side.
If the accounts belong to the vendor, the documented path is to stand up your own accounts and then move the apps. Both platforms support this and both attach conditions. Google requires that "Before you can submit a transfer request from your original account to a different account (known as your target account), both Google Play developer accounts need to be registered and active" — and with D-U-N-S registration taking up to 30 days, that step alone can set your timeline. Apple describes the equivalent operation plainly: "You’ll need to transfer the ownership of an app when you’ve sold the app to another developer or you want to move it to another App Store Connect account or organization", and reassures on continuity: "You can transfer your app while keeping it available for download on the App Store. During and after the transfer, the app retains its reviews and ratings, and users continue to receive updates."
Know what does not travel with the app, because these are the items that generate unpleasant surprises a week after a transfer completes. Apple states that "If you transfer an app that uses Apple Pay, the merchant ID isn’t transferred along with the app", and lists TestFlight betas, promo code generation and app bundle history among the things that do not carry over. Google notes that "Your bulk export reports, payout reports, and earnings reports won’t transfer with the app, so you may want to download any reports you’ll need later", and that test groups and promotions do not transfer either. Export your historical reports before the transfer, not after.
Then there is the clause that matters most in this section, and it is the one from Apple quoted in the key facts above: "The transferor is responsible for exchanging the actual code set and building assets directly with the recipient". The platform will move the listing, the ratings and the users. It will not move your source code. Code changes hands only because a contract obliges it, which is the whole argument of this article compressed into one sentence from Apple’s own documentation.
If the code is genuinely unrecoverable — no repository, no working build, no cooperation — the remaining option is a rebuild, and it should be costed honestly rather than treated as a disaster. A rebuild starts from a live product whose behaviour is fully observable, which removes most of the discovery risk that makes new builds uncertain, though it does not remove the work. Our published pricing tiers start at SGD 20,000 for a focused build, and the honest way to think about a rebuild is as a new project informed by an existing one. It is a poor outcome. It is also finite, which is more than can be said for waiting on a vendor who has stopped replying.
Questions to ask every studio you shortlist
Ask these before the proposal stage, when the answers are cheap to give and easy to compare. Every one of them has a short, specific answer if the vendor has thought about handover, and a vague one if they have not — the vagueness is the signal, not the words.
- Which legal entity will the Apple and Google accounts be registered to, and whose D-U-N-S Number will be used?
- Who will hold the Account Holder role in App Store Connect and the owner role in Play Console at the end of the project?
- Will the repository be transferred to an organisation we own, with full history, and who remains a collaborator afterwards?
- Does the contract assign copyright to our company, or grant us a licence? Show me the clause.
- What triggers the assignment, and what document records that the trigger has occurred?
- Which pre-existing or internal libraries will be in this build, and what licence do we get for them?
- Will we receive a list of open-source dependencies and their licences?
- What exactly is handed over on termination, on what deadline, and does that apply if the contract ends badly?
- Who holds the upload key, and is Play App Signing enabled?
- Can a third-party developer produce a signed build from what we will hold, without contacting your team?
The last question is the one to weigh most heavily, because it is the only one that cannot be answered with a reassurance. It describes a test, and a vendor comfortable with handover will treat it as a reasonable request rather than a sign of distrust. If you want a shorter version to use on a first call, ask the studio to walk you through the last time a client moved a project away from them, and listen for whether the process sounds rehearsed or hypothetical.
None of this is adversarial. A studio that expects to keep working with you for years has no reason to hold your accounts hostage, and a client who holds their own assets tends to be a calmer, longer-term client precisely because they are staying by choice. Clear ownership is what makes a long relationship voluntary on both sides.
How this works when you brief us
We publish our starting points so the conversation begins with facts rather than a discovery process: a focused Starter build from SGD 20,000, a Business app from SGD 38,000 and an Enterprise platform from SGD 90,000, with hosting, third-party service fees and app store developer accounts billed at cost rather than bundled into the price. Billing those accounts at cost is the practical shape of an arrangement where the accounts sit on your side of the line and the fees simply pass through.
The right time to settle every question in this article is the scoping call, before a quote exists. Bring the ten questions above and ask us the same way you would ask anyone else — the answers should be specific enough to write into a contract, and if any of them are not, that is worth knowing before you commit a budget. Ownership, accounts, keys and handover cost nothing to arrange at the start of a project and are the most expensive things to fix at the end of one. The same applies to what happens after launch, which we cover separately in app maintenance costs after launch.
If you would like these points reviewed against a proposal already sitting on your desk, send it over through the contact form and tell us what you are trying to protect. We are a development studio and not your lawyer, so treat this article as a checklist to take to one — the statutory positions above are quoted directly from Singapore Statutes Online and IPOS so you can verify every one of them yourself.
If a project ends and you cannot rebuild, publish and update the app without your vendor’s permission, you did not buy an app — you rented one.
Sources
Every external figure and quotation in this article was read from the body of the page that publishes it, retrieved over HTTPS with a browser user agent on 05 August 2026. Apple developer pages return HTTP 200 for non-existent paths, so each Apple URL below was confirmed by page content against a deliberate bogus-path control; Singapore Statutes Online serves provision text only through the ProvIds view, which was likewise checked against bogus-provision and bogus-act controls. Namtech pricing figures are our own published starting points, not third-party estimates. Nothing here is legal advice.
- Singapore Statutes Online — Copyright Act 2021, s 133 (First owner): "the first owner of copyright in a work is — (a) in the case of an authorial work — subject to subsection (2), the author".
- Copyright Act 2021, s 13 (Literary work includes computer program): "A 'literary work' includes — (a) a compilation in any form; and (b) a computer program."
- Copyright Act 2021, s 134 (Copyright created in the course of employment): "the employer is the first owner of any copyright in the relevant work".
- Copyright Act 2021, s 135 (Works commissioned before 21 November 2021): applies where parties "entered into an agreement ... before 21 November 2021" for a photograph, portrait, engraving, sound recording or film.
- Copyright Act 2021, s 137 (Transfer of copyright): "Copyright may be transferred as personal or moveable property by — (a) assignment; (b) testamentary disposition; or (c) operation of law."
- Copyright Act 2021, s 138 (Assignment — formalities): "An assignment of copyright is valid only if it is — (a) made in writing; and (b) signed by or on behalf of the assignor."
- Companies Act 1967, s 19(5) (Effect of incorporation): members "are a body corporate ... capable immediately of exercising all the functions of an incorporated company and of suing and being sued and having perpetual succession".
- IPOS — Ownership and Commercialisation (page states last updated 8 January 2026): "In general, the person who created the work (i.e. the author) owns the copyright in the work"; "We recommend having a written contract to document the assignment or licence."
- IPOS — Introduction to Copyright: "Literary works: Written works e.g. poems, lyrics, source codes".
- Apple — Become a member, Apple Developer Program: "you’ll be the Account Holder and must have the legal authority to bind your organization to legal agreements"; "Your organization must be a legal entity that can enter into contracts with Apple."
- Apple — D-U-N-S Number (Membership help): "Companies and educational institutions must provide a D-U-N-S Number registered to their legal entity."
- Apple — Apple Developer Program Roles: "When you enroll in the Apple Developer Program or Apple Developer Enterprise Program, you automatically become the Account Holder for your membership."
- Apple — Role permissions, App Store Connect: the Account Holder "is the only user that can sign legal agreements, renew membership ... or create developer ID certificates"; "The person who completes program enrollment is assigned the Account Holder role."
- Apple — Overview of app transfer: "The transferor is responsible for exchanging the actual code set and building assets directly with the recipient"; "the app retains its reviews and ratings, and users continue to receive updates."
- Apple Developer Program License Agreement (PDF, copy served 05/08/2026), s 14.3: the agreement "may not be assigned ... without Apple’s express prior written consent and any attempted assignment without such consent will be null and void."
- Apple — Choosing a Membership: "Enrollment is 99 USD (or in local currency where available) per membership year."
- Google — Choose a developer account type: "To create a developer account for an organization, you must have a D-U-N-S number."
- Google — Required information to create a Play Console developer account: "This process can take up to 30 days so you should plan ahead."
- Google — Add developer account users and manage permissions: "There are three different access levels ... account owner, admins, and users."
- Google — Transferring ownership of a Play Console developer account: "Only the account owner can transfer ownership of a developer account."
- Google — Transfer apps to a different developer account: "both Google Play developer accounts need to be registered and active"; "Your bulk export reports, payout reports, and earnings reports won’t transfer with the app."
- Google — Use Play App Signing: "Google manages and protects your app’s signing key on the same secure infrastructure that Google uses to store its own keys."
- Google — Get started with Play Console: "There is a US$25 one-time registration fee".
- GitHub Docs — Transferring a repository: "The original owner of the repository is added as a collaborator on the transferred repository"; "To transfer a repository you must have administrator access to the repository."
- Namtech — pricing: our own published starting points and the statement that app store developer accounts are billed at cost.