nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do you best organize iOS and Android development of the same app in Jira?

Christian Schmidt_x1wjz8

Dear Community.

I am working on a project, where we are developing an iOS and an Android version of an app.

I am curious how to best organize this in Jira, and I would love your input, and hear of your experiences.

So far, I have made a custom field, which is required, indicating whether the issue relates to iOS, Android or both.

But here is where the way to do it, can go in several directions.

Are you splitting the work on a User Story level?

A User Story concerning feature X is made in two identical versions - one for Android and one for iOS. They have their individual estimate.

Are you splitting on a subtask-level?

A user story concerning feature X is made, and on a task level, you differ between iOS tasks, Android tasks and common tasks. The story has a common Story point estimate for the whole team, which contains both Android and iOS developers.

I can see pros and cons to both strategies.

Much of this debate is related to how you are running your agile teams (have you split them into Android and iOS teams), and not Jira directly, but since how I am going to organize it will be reflected in Jira, I am right now seeking inspiration.

I hope you can enlighten me

Best regards

Christian

Accepted answers

All comments

Shaakunthala_5h8fhb

Hi Christian,

Interesting question, and I'd love to continue this discussion.

I have a question - is there any particular reason to use a custom field instead Components in JIRA? Components can be used to specify a given issue as iOS/ Android/ Both.

Splitting a user story into two stories is a good strategy in cases where development work associated with iOS and Android significantly differ. This is not to be a strict rule, but depending on the story team can decide it during iteration planning.

In other cases where development work associated with both platforms are much similar, you can use both components for the same story (multiple components for a single issue). In this case, just create Android/ iOS/ common subtasks.

Bottom line: Best strategy is a case-by-case strategy and it's up to the team to decide during iteration planning/ backlog grooming.

Please let me know how it goes.

Thanks!

Shaakunthala

Thomas Bjerring

If the choice is to use subtasks split into iOS and Android versions, is there a way of not showing the overall story on the board, which in our case is assigned to the team PM?

Sneha Sasikumar_mvtj3p

I am facing a similar challenge, am working on JIRA PoC for my customer and account. We have picked couple of projects and one of them is a mobile app team.

The challenge that i have are as below

1. A particular feature needs to be rolled out in both iOS and Android - both the dev team is different

2. There is an API team which is common to both iOS and Android team.

3. There is another team which is not part of the app project but we are linked to them heavily consider it more like an upstream application from where data is retrieved to and fro consumed by the mobile app/api team

4. I have a common QA team to test the mobile app

The upstream website team is created as a project. The mobile app is created as a project.

Now if i have a feature - am creating this as an epic and breaking it down into user stories. What i have done is create components as iOS, Android, API, WCS (incase of website) and then creating sub tasks under that user story.

This is because both the apps will go into public store (production) on the same date even though they are being developed by separate sub teams. This is helpful cause unless both apps are build for the user story that particular user story will not go into public stores.

So say, i want to enable Registration as a feature on my app then my Epic is Registration, then i create user stories say US A, US B, US C. all three are applicable for both ios and android so it will have subtask say, US A_ST_iOS, US A_ST_Android, US A_ST_Api, US A_ST_WCS.

Let me know if this helped!

Vitalii_wj7m1l

Hi @Sneha Sasikumar,

Thanks for sharing your approach.

May I ask a question regarding estimation.

1. Do your teams estimate in Story Points or in Hours?

2. On what level your teams put their estimations - stories or sub-tasks?

2.1. In case of story level - how do you manage different estimation for Android and iOS? Do you sum it?

2.1.1 How do you check capacity before planning?

2.2. In case of sub-task level - How do you check capacity before planning? Do you check only remaining time (as it is the only way how to sum sub story estimation)?

In general thanks @Christian Schmidt for rising this question. I have the similar situation that I'm looking forward to hearing any ideas how to organize it.

I can share my thoughts:

- currently we have 2 projects for iOS and Android. We do a separate capacity calculations, in most cases separate refinement due to different velocity of teams (it means that one team can already implement some features that other haven't started). And this approach works more or less fine but I don't like that we should clone (duplicate) our features and epics for teams. It because there is a lot overhead in supporting this features and tasks (you should change on the first project and then you should not forget to do the same for another one). To avoid text duplication and to have it the same for both teams I even think to have story description in confluence. But to be honest I doesn't like this idea!))

- Also I think about the following approach: to have all features as epics with one description and then just to create a stories for both team with titles and empty description. What I don't like in this approach that is my jira I cannot move epics into a backlog level and it will make a mess in a future with this tonnes of epics on the left panel;

- One more idea is to create a common Kanban board that contains descriptions for stories and Android and iOS projects will have links to this board. But supporting this might make even more mess.

It's interesting to hear your thoughts about it.

BR,

Vitalii

Omnia Mohamed

HI Vitalii,

I have the same problem but worst i have four platform Android TV , Apple Tv, iOS Mobile, Android Mobile, and each platform has a different release plan according to team capacity and users segmentation.

So to track the delivery we have four jira projects , for each platform a jira project , it's perfect to track the progress however it's so messy to duplicate the user stories across the four projects considering that all user stories has common acceptance criteria with percentage 70%

So Does any one suggest a good solution ?

I suggest to has one common user story that contains the common functionality/ acceptance criteria on confluence and link it in jira User story however i don't recommend that

Carlos Khatchikian

Hey Christian,

my name is Carlos, I am the Team Lead of Jira Mobile here at Atlassian and I wanted to share how we do things here...

Before we had 1 project for iOS, Android and Backend. We had components for each and we had 2 different boards separated by this components. In the end it didn't work well because you have different release cycles and different release versions, different story points estimations, different labels, etc etc...

In the end we finished with 2 projects. One for iOS and one for Android. Backend is done in any of those projects basically because the mobile devs know how to do backend. Releases, versions, and workflows are clear for what each team is releasing right now. And yes we have to duplicate Epics and User Stories. But I found myself that each team works differently and this gave enough room for every team to behave as they wanted.

Now this setup works because we have one separated team that does iOS and one separated team that does Android. If by any chance you are working more on a Squad model you might want to have 1 project and have maybe a custom field per squad.

Hope this helps!

Rich Byard

But when we have multiple projects it will be 2 separate projects (android & iOS) for each project?. Do you have a better way of handling this multiple project scenario?

FYI - we have separate devs for iOS and android

Thanks

Chris Saunders

Hi all,

it seems there are many of us on this same journey!

Interesting to hear that Atlassian team themselves are battling this same issue

We have an iOS, Android (with shared QA) and backend team.

We have common stories as well as platform specific bugs/tasks

I think I've been through most of the setups that have been described above and have realised benefits and drawbacks in each approach!

The biggest issue I've found with discrete projects (which work best for the teams), aside from the risk of inconsistency in stories, is that looking much past the next sprint managing the backlog priorities is a nightmare! Especially when interdependencies are thrown in to the mix!

I'd be glad to hear of any further insights.. We've started using portfolio which looks like it might fuel more revisions to our process but I fear it's actually just going to kick me off in another circular hunt for utopia...

Rayen Magpantay_9q36xa

Hi Chris,

I'm a Product Manager in the Jira Mobile team. Do you want to chat sometime? I'm keen to understand mobile development workflows and see how we can support you better here. We can share what we do internally, maybe you can learn from us and we can learn from you. Please shoot me an email at rmagpantay@atlassian.com if you're interested.

Thanks!

Rayen Magpantay_9q36xa

Hi all,

I'm a Product Manager in the Jira Mobile team. Do you want to chat sometime? I'm keen to understand mobile development workflows and see how we can support you better here.

We can share what we do internally, maybe you can learn from us and we can learn from you. Please shoot me an email at rmagpantay@atlassian.com if you're interested.

Thanks!

Hassa Islam

Hi,

I have been working as Product owner in multiple team, What I did previously,

- I created 1 project and where I add custom field which describe iOS, Android, Backend API, Designer and QA Task within same Epic.

- But in above mention point, I duplicate each user story and task separate for Android and iOS.
- After that in one Sprint each team member select user stories according to the business value and proceed accordingly.

- Scrum Team filter their task on Board and proceed on their deliverable

I also did separate Project for both Android and ioS but in that case i feel that QA, Designer and Backend API developer would not sync with any one of the Project if we place it in one project.

That's why i choose to work with above approach.

If you have any better suggestion, Please advice

Regards,

Hassan I

zoha131

We are a small team. Android, IOS, WEB & API each team consists of a single member.

This is how I am planning our project:

1. Four different components for each team with default assignee.

2. Epics for features. In each epic, we will multiple issues.

3. In each issue, we will have subtask for each component. Here we will duplicate issues for each team.

4. We will use the same MAIN versions across all team. For hotfix versions, we will use a tag for that as Jira doesn't allow versions for the component.

Eager to know what others think about this approach?

Rayen Magpantay_9q36xa

Hi Zoha,

I'm a Product Manager in the Jira Mobile team. Do you want to chat sometime? I'm keen to understand mobile development workflows and see how we can support you better here.

We can share what we do internally, maybe you can learn from us and we can learn from you. Please shoot me an email at rmagpantay@atlassian.com if you're interested.

Thanks!

Ahmad_6h9d1v

Hey Christian,

We have the same case that you have triggered to differentiate between iOS & Android in JIRA using SCRUM board,

Did you find any feasible solution to overcome duplication of projects, stories & tasks for each team (iOS, Android)?

Is there any new features expected in JIRA to overcome this hurdle

Thor_shxak9

@Rayen Magpantay I really would like to see your comment of this.

We have a single development team working on all three (iOS/Android/web portal) at the same time. Does this level of complexity make a difference in terms of how we manage the three projects, as opposed to if we had multiple teams?
In terms of using Scrum and planning in sprints: To manage all three projects, do we have to start three separate sprints every two weeks? Can we not define a single „master sprint“ that covers work on all three projects. As we have a single team, do you have any recommendations regarding how to plan sprints, future releases and measure velocity – without overview and planning becoming too complicated?

Mansoor Ali_uqdtfv

I am working as a Project Manager for a product development company, we have different teams for each section of the product, Android, API Backend, Control Panel, Designers, iOS, QA, Stakeholders.

Currently, I have following configuration/workflow

1. There is only 1 project for all of the above

2. Each new feature has an epic, and user stories as per the different business logic.

3. Each Team creates their own tasks and sub tasks, including designers

4. QA gets user stories assigned to test.

5. QA creates bugs under each task, and so on...

This way all my meetings include member from each team, and keep each one of us updated on the progress and upcoming risks.

Separating would create a chaos or miscommunication.

I was looking for an element, a defined field which would let me define the section of the task/ticket (Android, iOS, etc...)

Devin Booker

Hi Christian,

It's great to hear about your project for developing an iOS and Android app! Organizing tasks in Jira effectively can significantly enhance your team’s workflow.

Regarding your question about structuring user stories and tasks, both approaches you outlined have their advantages:

1. Splitting on User Story Level: Creating separate user stories for iOS and Android can help clarify the individual requirements and ensure focus on platform-specific nuances. This method allows for tailored estimations based on the specific complexities of each platform. However, it might lead to redundant effort if the features are very similar, as you would end up duplicating work.

2. Splitting on Subtask Level: This approach allows you to maintain a single user story, which can promote a clearer understanding of the feature as a whole. You can then create subtasks for iOS and Android, which helps in tracking progress in a more consolidated manner. This can also foster collaboration between the teams and lead to more cohesive development, as developers work towards a common goal with shared story points.

Ultimately, the best choice depends on how your agile team is structured. If your team is split into dedicated iOS and Android groups, managing separate user stories might work better. Conversely, if you have a more integrated team, using subtasks could streamline your process.

You might also consider using components or labels in Jira to easily filter and manage tasks based on the platform. It can provide a clearer overview without cluttering your backlog with duplicated user stories.

Don’t forget to take advantage of customizable Jira dashboards to visualize the progress on both platforms. This will help the entire team stay aligned and aware of the overall project status.

If you’re looking for further assistance or tools that can enhance your workflow even more, feel free to reach out! We offer services that can help optimize your project management processes and improve collaboration among your teams.

Jean-Paul Mugrditchian

Thank you for this approach. We had previously had separate projects for web, mobile, and website (WordPress) even though we only had two teams and one of those teams was supporting all three efforts. After reading your message, I was convinced that merging everything into a single project makes the most sense since all are essentially servicing one "product". Thank you again!

Mansoor Ali_uqdtfv

hey @Jean-Paul Mugrditchian ,

I also have couple of automation rules and conditional workflow.

If you want we can discuss and can share the workflow to achieve better automation and team focus and productivity.

Thanks,

anna drozd_pmvrdn

Coordinating iOS and Android development can be tricky, especially when trying to keep features and timelines aligned. Clear task management and consistent communication are key. If you're looking for support on the iOS side, this might help — a best iOS app development company with experience in cross-platform planning and native app delivery.

techqware

Choosing between splitting work at the Story or Sub-task level ultimately depends on your team's synchronization; if your developers work closely on the same feature set, using a single User Story with platform-specific Sub-tasks (iOS, Android, and Backend) keeps the backlog clean and ensures feature parity. However, if the platforms operate at different speeds or require vastly different UI logic, splitting them into separate linked Stories allows for more accurate individual estimation and independent release cycles. As a specialized iOS App Development Company, TechQware often find that using Components in Jira to filter these tasks is the most efficient way to maintain a "Single Source of Truth" while giving developers a platform-focused view.

Xcentric

Businesses looking to strengthen their online presence should consider how mobile technology can support their customers. A properly developed Android application can improve accessibility and engagement.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-development

development

new-to-jira