I’m working with several iOS client applications that are very similar to each other. Currently I manage them using different git branches where each app is a separate branch that gets cloned and merged back to the main branch when needed. Sometimes I need to make universal changes or bug fixes that affect all applications and should be applied to the master branch first.
Now I want to switch to Jira for project management but I’m not sure about the best approach. Should I create separate Jira projects for each iOS app? If I do that, how would I track and manage those universal changes that need to be applied across all apps?
I was thinking about using Jira components instead of separate projects, but I can’t figure out how to properly assign tasks to specific components. What’s the recommended way to structure this kind of setup in Jira?
We dealt with this exact situation for three related iOS apps at my last company. After testing both ways, I’d go with separate Jira projects but link them for universal changes. Set up a master project called “iOS Core” for features and bugs that hit all apps. When something needs to go everywhere, create the main ticket in the core project, then link it to “implements” or “relates to” tickets in each app project. You’ll get way better reporting and can track app-specific metrics easier while still seeing the big picture stuff. Just make sure you set up automation rules so status updates sync between linked tickets. Use the portfolio features if you need a consolidated view across everything.
Had the exact same problem with four iOS apps that shared code. We went with one Jira project and used components for each app - way better than separate projects. Here’s what worked: Set up component permissions properly and use epic linking for features that span multiple apps. When you need universal changes, create a parent epic called “Universal Feature” or “Cross-App Bug Fix” and link child stories to each app component. You’ll see everything across all apps but still keep app-specific stuff separate. We used tons of labels too - “universal-fix,” “core-feature,” whatever made filtering easier. The best part? Everything’s in one dashboard. During sprint planning, you instantly see dependencies between apps instead of switching between projects constantly. Just nail down naming conventions for components and labels before you start, or it’ll turn into a mess fast.
We tried both approaches and went with a hybrid solution. One main JIRA project, but we use the versions field creatively - each iOS app becomes a version. For universal stuff, we just assign multiple versions to the same ticket. Works pretty well and you don’t lose visibility like you would with separate projects. Takes some getting used to though.