Technology

Objective-C App Support, Migration & Modernisation
the language is still supported. The old code around it is the problem.

For businesses with an iPhone, iPad or Mac app written in Objective-C that has not been updated for years. We assess the code and its libraries, get it building on a current Xcode, keep it supported, and move it to Swift a screen at a time where that is worth doing.

Request an Objective-C assessment Discuss an existing Objective-C app
More about this service

We are an Australian team working remotely with businesses in the United States, the United Kingdom, New Zealand and Australia. Every engagement starts with a scoped technical assessment, so the estimate that follows is based on your code and your data.

  • Assessment A scoped technical review before any estimate
  • 18+ yrs Building business software
  • Independent No licence commission, no reseller agenda
  • US UK NZ AU Australian team, working remotely
Australian owned and operated

Built here. Your data stays here.

  • No offshore development. Everything is written by our own team in Australia. Nothing is subcontracted overseas.
  • Your data stays onshore. Hosted in Australia, on infrastructure you own, under Australian law.
  • Every state, not just ours. Perth, Melbourne, Sydney, Brisbane, Adelaide and everywhere between.
Objective-C developers

Still supported, still working, and stuck on an old Xcode

Objective-C is how iPhone, iPad and Mac apps were written before Swift, so a great many business apps are written in it: order taking on an iPad, inspections in the field, a Mac tool the office runs on. Apple still supports the language, and an app that was built well keeps working for years without anybody touching it.

Read more

The trouble starts on the day somebody needs to change it. The project will not build in a current Xcode, libraries installed through CocoaPods have been abandoned, parts of the code call programming interfaces Apple has deprecated or removed, and the App Store will not take an upload built with old tools. Each has a known answer.

Our Objective-C developer service is for businesses in Perth, Melbourne, Sydney and Brisbane. It covers three kinds of work: code fixes and updates, migration to a modern technology stack, and ongoing maintenance and support.

See legacy software modernisation

Three ways forward for an Objective-C app

The second is the one most apps need first.

  • Keep it and support it

    The app stays in Objective-C. We get it building, put the signing certificates and profiles in order under your own Apple developer account, fix faults and make changes. This suits an app that works and mainly needs somebody who can release an update.

  • Bring it up to a current Xcode

    The same code is updated to build with a current Xcode and software development kit (SDK). Deprecated calls are replaced, libraries are upgraded or swapped, and the app is made ready for review. New screens can be written in Swift beside the old code.

  • Replace it in stages

    Where the code is too tangled to change safely, the app is rebuilt in Swift one screen or one feature at a time, inside the same project and against the same server and data.

What we do with Objective-C apps

Six kinds of work. Most engagements are two or three of them.

  • Objective-C maintenance

    Faults fixed and changes made in existing classes, screens and storyboards, from the Xcode project.

  • Library audit

    Every third-party library listed, whether it came through CocoaPods, Carthage or a copied folder, with whether it is still maintained.

  • Xcode and SDK updates

    The project brought up to a current Xcode, with deprecated interfaces such as UIWebView and UIAlertView replaced.

  • App Store resubmission

    Signing, privacy declarations and review questions handled, so an update can be released again.

  • Swift beside Objective-C

    New features written in Swift in the same project, and old classes converted where that pays for itself.

  • Mac app updates

    Mac apps rebuilt for 64-bit and Apple silicon, then signed and notarised so that current macOS will open them.

Supporting it, updating it and rebuilding it are different projects

Each trades cost against how much of the old code remains afterwards.

  • Stay in Objective-C

    Lowest cost. The code is documented and supported, in a language Apple still supports. Fewer developers work in it each year, and the yearly Xcode update still has to be done.

  • Update it, and add Swift

    Most of the code is reused and staff keep the app they know. It builds on current tools and passes review. Two languages live in one project, which Apple documents and supports.

  • Rebuild in Swift

    Nothing depends on the old code afterwards, and the design can be brought up to date. It takes longest, and is only worth it when the app has years of change ahead of it.

What an Objective-C assessment looks at

Objective-C the language is current. The risk is in old code, old libraries and the store rules. The dates and requirements below are from Apple, and the CocoaPods date is from that project.

  • Which Xcode built it

    The Xcode version that last built the app. Since 28 April 2026 Apple has required uploads built with Xcode 26 or later, and it raises that every year. A current Xcode needs a recent macOS, so the Mac that built the app years ago may not do.

  • Whether the source is complete

    Header and implementation files (.h and .m), storyboards and .xib screen files, and the Xcode project (.xcodeproj). A business that holds only the copy on the App Store can use the app but cannot change it.

  • Third-party libraries

    Libraries brought in by CocoaPods (a Podfile), by Carthage, or copied in by hand. The CocoaPods project has set 2 December 2026 as the date its central index stops accepting new versions. Abandoned libraries are found first.

  • Deprecated interfaces

    The App Store stopped accepting new apps that use UIWebView in April 2020. UIAlertView and OpenGL ES are deprecated. Apple has also said that apps built with the SDK after iOS 26 must adopt its scene-based life cycle, or they will not launch.

  • Signing and release route

    The App Store, named test devices, or in-house under the Apple Developer Enterprise Program, and whether the certificates and profiles are current. Apple states that an in-house app can no longer be run once its distribution certificate expires.

  • Devices and iOS versions

    Apple lists iOS 15 as the oldest version that Xcode 26 and 27 build for. An older iPhone or iPad that cannot be updated that far cannot run a new build, which matters for a fleet of shared devices.

  • Mac apps

    macOS Catalina 10.15 stopped running 32-bit apps. Apple says Rosetta, which runs Intel apps on Apple silicon Macs, will be available through macOS 27. Software distributed outside the Mac App Store has to be notarised by Apple.

  • Server, data and notifications

    How the app reaches its server, what it stores on the device, and how notifications are sent. Apple stopped supporting its older notification protocol after 31 March 2021, so the server side is checked as well as the app.

An Objective-C app nobody can get back into the App Store?

Call 0425 531 127 or Request an Objective-C assessment

What the assessment needs from you

A fixed-scope piece of work with a written result: the options, the risks of each, and a staged estimate. No production data is sent by email. We agree a secure way to share it first.

  • Versions

    The Xcode version that last built the app, and the iOS or macOS versions it runs on.

  • The source

    Whether the full Xcode project exists, where it is kept, and whether anybody has built it recently.

  • Libraries

    Any third-party libraries you know of, and whether you hold licences for the paid ones.

  • The Apple account

    Who owns the Apple developer account, and who can sign in to it today.

  • How it is released

    The App Store, an in-house install or a device management system, and when the last release was.

  • Users and devices

    How many people use it, and which iPhone, iPad or Mac models they have.

  • Integrations

    The server it talks to, sign in, notifications, payments and any hardware it connects to.

  • What is hurting

    The two or three problems that started the conversation.

  • The way back

    How long staff can keep working on the current version if a new release has to be withdrawn.

How it runs

From assessment to a supported iPhone or Mac app

Done remotely, with meeting times agreed to suit your time zone.

  1. Technical assessment

    We establish the Xcode version, what source you hold, every library the app needs and how it is signed and released. You get a written list of options with the risks of each and a staged estimate.

  2. A working build

    The project is made to build on a current Xcode and run on a test device, and the result is compared with the app you use today. Until that works, no change is safe.

  3. Proof of concept

    One representative piece, usually a deprecated interface replaced or one screen rewritten in Swift, is taken end to end and through a test release.

  4. Staged work

    The work is done in stages agreed from the assessment, each with its own scope and estimate, starting with whatever is blocking a release.

  5. Device and user testing

    The app is run on the iPhone, iPad or Mac models your staff use, through TestFlight or an in-house install, and your staff test the work they do every day.

  6. Release and support

    Each release is planned with a way back. We watch the first days of live use, then keep the app current with each new Xcode and iOS for as long as it stays in service.

What people ask us about Objective-C

Is Objective-C still supported?

Yes. Apple still supports Objective-C in Xcode and documents using Objective-C and Swift together in one project. What goes out of date is everything around the language: deprecated interfaces, abandoned libraries, and the Xcode version the app was last built with.

The app still works. Why would we touch it?

Often you should not, and we will say so. The trigger is usually a change nobody can make, a new iPhone or iOS version that breaks something, or an upload Apple refuses. Apple can also remove an app from the store when it has gone three years without an update and is rarely downloaded.

Do we have to rewrite it in Swift?

No. Apple does not require Swift, and the two languages work side by side in one project. A common plan is to keep the Objective-C that works, write new screens in Swift, and convert an old class only when it needs changing anyway.

Why will the App Store not accept our update?

Usually because it was built with an older Xcode than Apple now requires, because it targets an iOS version older than Apple accepts, or because it lacks the declarations Apple has required since 1 May 2024 for certain programming interfaces. The rejection names its reason, and each has a known fix.

We cannot find the source code. Is that fatal?

It is serious, because an app from the store cannot be turned back into source code in any useful way. Old laptops, backups and code hosting accounts are worth a proper search first. If the source is gone, the app is rebuilt, with the old one, its server and its data as the specification.

Our Mac app will not open on a new Mac. Can it be fixed?

Usually, if you hold the source. A 32-bit app has not run since macOS Catalina, and an Intel-only app depends on Rosetta, which Apple says will be available through macOS 27. The app is rebuilt for 64-bit and Apple silicon, then signed and notarised.

Do you provide Objective-C developers in Perth, Sydney, Melbourne and Brisbane?

Yes. We are an Australian team and we take on Objective-C work for businesses in Perth, Sydney, Melbourne and Brisbane, and elsewhere in Australia. Most of the work is done remotely, by video call and screen share, with secure access to a copy of your system. The service is the same in every city: code fixes and updates, migration to a modern technology stack, and ongoing maintenance and support.

How does this work from the United States, the United Kingdom or New Zealand?

Remotely. We are based in Australia and do not have offices elsewhere. Discovery is done by video call and screen share, with meeting times agreed to suit your time zone. Confidentiality, who can reach your systems and where your data is held are agreed in writing before work starts.

What does it cost?

The assessment is a fixed-scope piece of work with an agreed fee. The estimate for anything after it comes from what the assessment finds, in stages, so you are not asked to commit to a whole project on a guess.

Tell us about your Objective-C app

What the app does, the devices it runs on, whether you hold the source, and what is forcing the question. Include your country so we can suggest meeting times. Please do not send production data.

Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.

Kasun Wijayamanna, founder of HELLO PEOPLE

Kasun Wijayamanna, founderYou deal with Kasun from scope to delivery. No account managers and no offshore handoff.