Work with Zynx
Bring a brief, a prototype or an existing app.
We design and build apps for iPhone and iPad. Share where your project is now and we will discuss the people it serves, the work involved and a sensible next step.
Apple app development starts with a useful purpose.
An app brief can begin with a repeated frustration, an existing manual process or a product idea. The useful starting point is a specific person trying to finish a specific task.
We work with founders and businesses to define that task, identify what the first release needs and separate later ideas from the work that makes the product useful now.
Projects usually start in one of three places
- Feature 1
A new iPhone or iPad app with a clear audience and purpose.
- Feature 2
An app concept that needs a practical first-release scope.
- Feature 3
An existing design ready to be reviewed for development.
Working with an app developer in Sydney.
Zynx is an independent studio based in Sydney. You deal with the people designing and building the app rather than an account manager, and reviews happen on real devices in Australian business hours.
We publish our own software as well as building for clients. Modes Media Player is on the App Store, so the standard of our work is something you can download and judge for yourself before you commission anything — which is a fairer test than a folder of screenshots.
Projects run remotely by default and that works well for clients outside Sydney. Say where you are based in your enquiry so we can agree how reviews and any in-person sessions should work.
What working with a Sydney studio looks like
- Feature 1
An independent Sydney studio with its own published iPhone and iPad app.
- Feature 2
Direct contact with the people doing the design and development work.
- Feature 3
Australian time zone for reviews, questions and release coordination.
Agree what the release will actually do.
We connect the main screens to the actions behind them: how people begin, what information they need and what happens when a task succeeds or fails. Features such as accounts, payments, syncing and integrations need their own scope; they change the work beyond the screens.
The proposal should name the supported devices, essential features, review points and handover materials. If you need other platforms, describe them in your enquiry so we can discuss the fit before committing to delivery.
What the proposal names
- Feature 1
A defined first-release feature list and user journeys.
- Feature 2
Working app screens and behaviour for the agreed scope.
- Feature 3
Device testing, issue review and release preparation.
- Feature 4
A handover covering the agreed source files and build information.
What actually drives the cost of an app.
The number of screens is a poor predictor of effort. What moves a quote is whether the app needs accounts, whether it takes payments, whether information is shared between people or devices, whether it must keep working offline, and whether it has to talk to software you already run.
We work through those five before quoting rather than after, and we will say when something on your list costs far more than it returns. Bring the budget range you are comfortable discussing: it decides which version of the idea is worth designing, and it is a more useful starting point than a feature list.
The five things that decide a quote
- Feature 1
Accounts, sign-in and anything holding personal information.
- Feature 2
Payments, subscriptions and the rules around them.
- Feature 3
Sharing or syncing data between people and devices.
- Feature 4
Working offline, and what happens when a connection returns.
- Feature 5
Integrations with the systems your business already depends on.
Review the product by using it.
Working builds give a project something concrete to review. Feedback should describe the task, what happened and what the person expected, so a problem can be reproduced and resolved.
You bring knowledge of your customers, brand, content and business rules. We bring that information into the app and make the remaining decisions visible. Changes to the agreed scope are discussed before they become extra work.
Explore a product from the studio.
Modes Media Player is our audio and video library for iPhone and iPad. It brings personal modes, artwork, playlist sharing and native playback into a product you can explore through real screens and demonstrations.
Its product page shows the actual interface and supported features. It is a useful starting point for a conversation about the experience you want to build.
Prepare your iOS app for the App Store and beyond.
Before release, agree who manages the store account, product copy, support channel and future updates. Store submission, review and any follow-up work should be included explicitly in the project scope.
Ongoing maintenance is a separate decision. Tell us if you need continued development or help planning the next release so those needs can be discussed from the start.
Common questions
Frequently Asked Questions
Do I need a finished design before getting in touch?
No. Share the problem, the intended users and anything you have already explored. Product design can help define the experience before development starts.
What determines the project scope?
The main user task, supported devices, features, existing designs, external services and release requirements all matter. We discuss those inputs before defining the work.
Can you guarantee App Store approval?
Apple makes the review decision. Submission preparation and any work responding to review feedback need to be agreed as part of the project.
How much does it cost to develop an app in Sydney?
Cost is driven by accounts, payments, data sharing, offline behaviour and integrations rather than the number of screens, so any figure quoted before those are discussed is a guess. Share a budget range early and we will tell you honestly what fits inside it.
Do you work with businesses outside Sydney?
Yes. Projects run remotely by default, which works for clients anywhere in Australia. Tell us where you are based so we can agree how reviews and any in-person sessions should work.
Can you take over an app someone else built?
Sometimes. It depends on the state of the source files, the accounts, the frameworks used and what is documented. We would review those before agreeing to anything, and we will say plainly if a rebuild is the more sensible option.
Who owns the app and the source code?
Ownership, the App Store account, the source files and responsibility for future updates are agreed in the project scope before work starts.