Hello, hello, and welcome to the App Store Connect group lab. I'm Laurel, and I'm from the App Store Connect engineering team. App Store Connect is the developer gateway to the App Store. We provide helpful tools for developers to launch their apps, get discovered, and build their businesses. I've got a fantastic group of experts here with me today. I also have to shout out our most excellent group behind the scenes that's supporting us. Let me go around and introduce my panel. I'm going to have everybody say their name, what they work on, and their favorite feature that was announced this week for developers. Jeff, you can go first. Excellent. I'm Jeff. I'm an engineering program manager on App Store Connect. And my favorite feature from this week was adding in-app purchases to the enhanced submission experience. It's been a long time coming, and we're finally bringing everything together where developers will have even more control over what they submit together, what gets reviewed together, and also be able to see messaging all in the same place for their app, their app's content like in-app events, and now their in-app purchases too. It's very exciting. Yeah. My name is Lydia. I'm a quality engineer on App Store Connect. I'm really chuffed about the addition of localization for background assets. I think it's going to be great that developers can add localizations, but customers don't have to download all of the localizations, just the ones that they need for their localization. Very nice. My name is Nick, product manager for the App Store, and I'm really excited about all the stuff coming in Xcode related to AI, which makes it easier for anybody who maybe doesn't even know how to code very much to develop a really high-quality app, submit it to the App Store, and bring it live to the world. Hello, everyone. I'm Shobi. I'm an Apple engineer. As a developer myself working on TestFlight and App Store Connect apps, I'm super excited about using custom images and videos for the product page headers and search results. This is going to enhance my app's presence on App Store, and I'm pretty thrilled about it. It's pretty cool. It is. Hi, I'm Dave, part of the App Store Engineering, working on TestFlight and App Store Connect. And I think my favorite feature that we announced is the Asset Library in App Store Connect, a way of managing your images and using them across different placements. So I'm pretty excited for that. I like that one too. Okay, so we're going to jump into questions. We have a question here from eDorphy, what are the most overlooked App Store Connect APIs or capabilities that developers should be taking advantage of today? So maybe specific to the App Store Connect API, what APIs do you think developers should be using if they're not already? I can take that. Basically, I would assume when you are actually developing and iterating for testing is the most of the time is spent on doing multiple API calls and re-invoking different builds uploads. So I would say build uploads, which was a feature that was launched last year, basically helps you to do this end-to-end with full automation. And you can upload a build, you can make that build available for test write testers, and you can get feedback, which is also a public API that's available for you to be able to consume, act on it, and upload another build. This whole process of development is completely can be automated with App Store Connect. I think that's the most best API that we have done and that's amazing. I was going to say that one too, like the combination of test flight feedback APIs and web hooks. For a long time developers have wanted this to be able to automatically generate tickets in their own ticketing system for things that they can follow up on. So I really like that one too. I also like, I think the power and performance API, there's your ability to download some reports and see how your apps are actually doing on the device and to give you this information is one that's I think a little underutilized. Yeah it's like storage and CPU usage right? Yeah. Okay from D Fabulich the accessibility nutrition label allows me to declare that my game has captions. My game doesn't have captions because it doesn't have sound. It's fully accessible to anyone with hearing disabilities. How do I signal that hearing impaired user to hearing impaired users that my app is accessible to them? It's a really good question. Really hard. Yeah, it is. I think we can all agree. It's hard for us to know exactly what is the right accessibility questions to answer for someone else's app. And I think it's important to look into answering those things your best ability on what does your app do? And so that customers who are looking for those accessibility things can see it. And, you know, how to answer for these questions, just kind of, you know, look through it and answer your best of your abilities. Yeah. And I think you even sort of said it in the question, if your game doesn't have captions, then don't say that it does. There are other ways, like in the app description, where you could say anything you want to lots of different audiences. And so I would take a look at that. I think app previews is another way. Someone's looking at their app on the App Store. They're going to see a preview of what your app does and how it experiences. And that's a great way of explaining to people when they're first seeing you off the App Store, what is your app like? Yeah. All the value propositions that you have, you can put it in there as well and make it really clear. Okay. Claire KC asks, what are the most common reasons subscription apps get rejected on their first review? And any pro tips for a new developer on submitting and on following up after rejection to get approved more quickly? This is something I feel like a lot of developers really care about. And we hear about at WWDC, people really wanting to nail it when they submit to AppReview. I think that preparation is really the key to a successful AppReview submission. You know, we're here to help you get your app onto the App Store. But preparation and ensuring that you've tested on a device the same way that you expect your users to use the app. That you've exercised the functionality to the best for your ability. You've addressed any crashes. That you've tested your IAP. Make sure it works. Make sure that your whole systems are production ready. And then also provide app review. Use the AppReview notes on the submission page to tell AppReview how they can use your app and any guidelines they have, including any login or demo credentials. And I think that last piece is really important. If you're a subscription app and there's certain stuff behind the paywall, you need to make sure that you put those credentials in the AppReview notes. There's a section for it so that when they come in, they can log in, they can see the full app. Some people forget that. The other piece is just relevant information and notes that you might want the reviewer to look at. Maybe you've considered or thought through. That can really help them so they're not looking at it blind. Yeah, I would also add like in-app purchase is something that you can actually test using sandbox environment when you are either using Xcode as well as when you use TestFlight. We would highly recommend like test your app. Make sure your subscription is actually working so that the app review becomes an easy step. Yeah, getting a good tester base before submitting, I feel like could be really helpful. And also plug for your favorite feature, the new enhanced E&App Revision Flow, because if there's something wrong with the E&App purchase, you're going to have much clearer communication with AppReview about it, specifically about that. And then just one more thing, the question mentioned how to deal with the rejection quickly. The other thing is to make sure that, you know, you'll get a detailed message from AppReview on your submission. And take the time to, and the App Store Connect feature to write a response, not just submit an update, but respond to app review and use that space to have a dialogue to explain the way your app works and ask them any more detailed questions you might have about the rejection itself if it wasn't clear. Yeah. Okay. Brew install Poppy says, So the retention messages API lets our app say, wait, babe, I can change right as the user is about to cancel. How cool is that? Now, on the analytics side, will ASC show impressions, save rate, and how often the user revisits the cancel flow? Nick? We can all change. And we will be giving a lot of data on this so that you can measure how it's working for you. will give how many people saw that retention messaging page, how many people clicked cancel, how many people continue to stay subscribed. And then you can test out different messages to see what resonates the most. You can offer them different plans. There's a lot you could do there. And we have a lot of data for that. Yeah, retention messaging in general is just very exciting. And I feel like it gives developers a chance to remind users about this app that they may not have used in a while. So it's really exciting. Okay. You can change. You can. Okay. Another one from E Dorphy. What are the most common security mistakes you see developers making when implementing App Store Connect API integrations? Hot take from me. I don't feel like we see that many. I feel like we see developers doing a really good job managing their API keys. but what are things that developers can do in terms of managing keys in the App Store Connect API? Dave? Yeah, I think the key thing is don't hard code your API keys into your repository. You don't want to store it there. You don't want to put it into any clients that you're shipping. And manage this private key responsibly. The great part is if you find that you have actually compromised your key or so you do something you shouldn't have, you can revoke it in App Store Connect. But I think basic key hygiene. And there are a couple of things that I see as well. So sometimes people will use the API for their own purposes and their own systems. Other times they're using it to integrate with third parties. And if you're doing that, you need to be especially careful. If you stop using that service, revoke that key. Be really careful about the permissions that you give to that particular key. don't over share information with those third parties um so certainly be be careful with those situations and some of that gets into user management too on an account it's like as people are working on the app or no longer working on it that i think is the really important time to um exactly work it to be working doing security right absolutely private keys are meant for your own private use it's not something that you need to be sharing with anything and if you're creating a key for a specific use case use it for that and then revoke it yeah so that's the best practice we also have users and access apis too that people can use to monitor who's on their account and compare that against their own internal systems or other things so that that would be the best thing i would think okay stigler farmers asks is apps in app store analytics is there a way to see how many people updated organically versus in the background. So auto update versus manual. Versus manual. Yeah, we do. So there are a couple of different places that you can get data on updates. One is in our dashboard, and then we also have reports. So the breakdown for auto update versus manual is in the reports only. But if you go online and you look at the analytics reports you can download that and see a column that breaks down auto versus manual okay Jonathan 889 says I work for a large company that has a lot of apps I know about some of those we want to automate uploading of only a few apps from CI. Creating a team API key gives access to all the apps, unless I'm mistaken. Yes it does. But we'd rather have a token that can only access a few apps. Is creating an account with a key the only way? This is a good one. It is a good one. We talked a little bit about how you can give API keys different users and different access controls, you know, whether it's developer, admin, or something like that, like you can for users in App Store Connect. However, for a general access key, you cannot change which apps it has access to. We do have a feature, I don't know if this is going to work in their case, where you can create a key per user of App Store Connect, and it's tied to that user's level of access. And so that'd be like an individual key. So if, you know, I happen to be, have the marketing role and I only have access to a couple of apps on the account, then I can create an API key that matches my same level of access and control. And this is a really great one now because we have some non-technical users like a marketer who maybe want to download reports and they want to download them every day and they just want to download a CSV. And with some handy AI tools they can do that themselves and just get completely set up with the exact same permissions of what they can do in the UI and They can just automate some of the things that they might be doing manually I think something the thing that's interesting about it in this case if you you know working large companies people may forget That that person's key was when they were using to upload all the apps Yeah when they you know leave and remove the access steps for connect all of a sudden automated system person that they've been depending on wasn't working So I think that's why I say I don't know if it works in this particular case, but this concept of testing things out works great. Yeah. Okay. This might be a hard one. Lazy Var asks, is it possible to set a different name and subtitle depending on target for universal purchases? For example, omit mentioning NFC for a TVOS target and or are there any recommendations or best practices when key app functionality differs per platform on universal purchase apps? This is hard. And this comment, like this comes up where people sometimes have different privacy practices on different platforms. So, yeah. Yeah, there's a whole set of information that's shared across all the apps. all the different platforms that your app is on. And as I mentioned, the name and subtitle, this is what gets shared across. Not only is it name and subtitle, but also your age rating and you share it across and the genre that you're in, the idea being, because once you get the app on one platform, then you can download it on the rest. And so this is really what makes your app your app. Description, however, is something that can differ per platform. So your Mac app has one description and then what people would, or in this case your tvOS app, can have a different description that doesn't talk about NFC, and your iOS app can talk about NFC. Yeah. Yeah, that would probably be the best place for it. Okay. Edorphy asks, does the new retention workflow support localization? If so, do we need to or do you recommend to localize our retention message to match all the localizations of the app itself? I can take that one. Yes, localization is supported. And you do want to have consistency in your localization. If you have localizations for your customers and you want to make sure that it's going to be consistent with the retention message that you're offering to them. Yeah, we've heard from some users in different regions that they have kind of a disjointed experience when they go from things that are really translated and personalized for them and then an English part of the experience. So I would definitely say. Match the language when you say, I can change, baby. Yeah. Okay. Ooh, username six cups of coffee. Wow. That's me. I like it. Okay. I see a lot of popular apps with dense copy in the description. While a lot of advice is not to use dense copy, what are the best practices for App Store app descriptions? I just think about what your users might be interested in and what you're trying to offer to them. As this question mentioned, sometimes people try to stuff as much information in there, but then for the people who are evaluating your app and thinking about whether they might want to use it, it may not be very enticing. So always keep your user front of mind. I think tailoring your message for your audience is a good idea. And, you know, if you're trying to figure out who your audience might be, you can take advantage of features like custom product pages and drive different audiences to different copies. Yeah. Or product page optimization to test two different. Yeah, that's what I would recommend. Like as a safe way to see if your description is too verbose. Yeah. Right. Yeah. using the product page headers and search results real estate now where you can upload your custom videos and images you can still tailor to the app description is not the only place yeah and yeah yeah i mean i hate to be that guy but a picture is worth a thousand words yes so you know yes throw it in there the new product page header will be yeah at the top now the first thing they see It's a compelling image or video. You can change it. You can use custom product pages or product page optimization. So not to vary away from reading. Reading is great. There's also going to be a super important image or video that's going to kind of convey more meaning. And then in your description, maybe it could be more factual. I don't know. But you should use a product page optimization to try. Okay. username, Hello Universe, Help, Which World See? S. Yes. What are the best practices for using test flight for internal team testing? And how about external testing, Shobi? Yes. So if you take care of, you are first developing your app. Before you go ahead and find out who your testers are, the best place to test is within your own team. That's where internal test flight comes in. Basically, internal people who are within your team can be added as App Store Connect users, and you can send an email invitation to them to say, hey, go ahead and test the app and provide feedback. This is also extremely useful if you have a QA team to whom you want to distribute bills on a regular basis. Once you have done the due diligence of an internal test flight and your app is working as expected, now it's a great time to go ahead and do external test flight, where you submit to beta app review process, And the app review process exists in order to ensure that it's trustworthy and content is all safe for both developers and testers within the world. And once it's approved, you have up to 10,000 testers. And it's very easy to find external testers. You have a link. You can go to any communities where your app is popular. I wouldn't say it's that easy. People say sometimes it's not easy. I know. You have to download the TestFlight app in order to be becoming a tester to it. Yes. But this is also to make sure this is coming from TestFlight, and it gives the trust and the privacy that what the testers look for. And that's the main reason. We want them to download TestFlight and distribute through that. And to help find people, there's forums. If you have a gardening app, there are gardening forums you can post there and try to get feedback. You're not trying to sell your app to that community. You're trying to help the community and honestly looking for feedback. And what we've seen is that when people are excited about their app and they're excited about the community, the community will give really useful and helpful feedback. And there's some people who are really excited about testing new software and want to try new things. Especially games. Got to get in front of them. Yeah. Especially games. And Lydia, talking about the internal testing, you use TestFlight to test. Yes. TestFlight. Absolutely. To TestFlight and internal pre-release features. This is also how we make sure this is ready to go live. Every bill that we give to you, Lydia, is through an internal test flight book. We test test flight through test flight. The other part of the question about what are the best practices for using it for internal team testing, there are different kinds of internal teams. So we have QA teams that might be dedicated and focused on the app, but we also have localization teams who are looking at something totally different, and you might want to create different internal groups for those. and give those teams different builds. And you can do that by creating different groups within the internal test flight and basically have a QA team who will probably get the build on an automatic basis on every build that goes to them. And you can have, what you said, a localization team and you choose what builds you want to give it to the localization team. And if you want to hear from leadership and feedback before you want to go external, you can create a team, you create a group that is specific for... Be careful about that build. Yes. - Special one that you're giving access to. - Okay, what advice would you give to developers, oh sorry, Edorfi, back with more API questions, which I really enjoy. What advice would you give to developers with respect to API keys, vending them to other tooling, using them within their own applications, and automation scripts? Keychain, principle of least privilege, limiting user access to apps are a few things that come to mind. I feel like we talked about this earlier, but people are upvoting it. So they still have questions about it. Yeah, you know, it's really important that API keys are meant to be on your server only. And we'll keep repeating that because sometimes it's like, oh, this is so easy. I can just put it into my app and then it can make all sorts of different calls if you want to build an app that you see, App Store Connect API. So putting it on the server is key. And just remember, there's no expiration date on this, putting the server, so that it's all like that. There's no expiration date on these keys as well. So, like, they last a long time. So pay attention to that. Yeah, if you create a team key, think about what role it has. Like, maybe you want to give lower-level permissions to just be reading data. But, like, an admin key can do quite a bit. And, you know, if what you're doing is you're trying to figure out how the API works and you're testing it, that's a great time to use those individual keys, you know, to just kind of try it out a little bit, see what you can accomplish, and before you want to move on to maybe that team-wide key that's going to be, you know, running in the server forever and not just, you know, locally on your computer to try out a few things. And I'm definitely a proponent of principal least privilege of the E-Dorf you called out, so I'd say I agree with that. Okay. All right. From Josh D., we want to be able to use the same product name on the App Store for our Mac app and our iOS and Apple Vision Pro apps combo. So it's like Mac here and then the other one is universal with iOS and Apple Vision Pro. But they have different bundle IDs. Last I checked, that wasn't possible. Has that changed? It has not changed. It has not changed. But we recommend, you know, there are a lot of good advantages to adding your Mac app to your iOS and Vision Pro app record and using universal purchase. And that would accomplish the goal and maybe give you some other benefits as well. Yeah, and, you know, when those names are being shared, it's good to remember that, you know, as the ecosystem has evolved, now you can, you know, have an iPad app be downloaded on your Mac. And so having these names be unique is really important as you're trying to disambiguate different apps. Yeah, I'd say we're building to benefit universal purchase apps, and we definitely want to have more features that make it more convenient for developers to have universal purchase across many platforms. But I think also all the way down in the ecosystem to Xcode, we're going to continue, I think, to see probably more features that support that kind of unified development on one bundle ID. So if it's possible, Josh D., to merge and come together, I know it's a lot. It's a lot to develop and migrate those users, but there are a lot of benefits down the line for that. Okay. So Al Sant says, for a developer building their first app with user authentication and third-party API keys, what's the most important thing to get right before submitting to AppReview for the first time? Jeff? Jeff? Yes. I think making sure that you've, again, same advice as the last time, different variation on it. Thoroughly tested the app, thoroughly tested the third party functionality, the third party APIs, and that the keys and that your services are ready to receive production traffic and ready for scale before you submit to AppReview, that everything is good to go from that standpoint is really one bit of advice I would give. - The other thing I don't know exactly what they mean by third-party API keys or how they're using them, but if it's your user's API key, I believe we want to see that you are also upholding privacy on your side of managing other people's keys and doing that in a really privacy-friendly way. So that's something that should be kept in mind. Correct. And, you know, let's not, again, I'm going to remind them for all my friends in app review that demo account information. I think Nick, you talked about it earlier. It's really good to have that so we can, you know, launch the app and review it with all the right setup and everything like that. Okay. Beloved Melody says, I'm nervous about transitioning my app from paid upfront version one to freemium version 1.1. Sounds like a path that's been paved before. With a purchase restoration pathway for those who purchased the V1, it would be devastating to fail to honor users' previous purchases. How do I know my purchase restoration testing code will work in the real world? Well, thank you, Melody, for thinking of your users and wanting to make sure that they continue to provide a good experience. Anybody have ideas what to do in that case? That's a tough one. Yeah, I think what you want to do, it's great. We have with the store kit to app transaction API, you're able to actually see the original app version that a customer purchased. And so you can kind of, if you want to be able to tell what they have and then be able to provide service based off of that, if that's how you want to go forward with that. Shelby talked about it before with TestFlight, that in TestFlight you can test all of these kinds of features and look at who has what purchases and how you want to behave with them test out some of those accounts. So I would recommend looking at the Storkit 2 API and also use TestFlight to make sure you got it right. Yeah. First is Xcode testing, and once it's ready, go for TestFlight testing. And TestFlight by default uses the sandbox environment, but your account is still the production account that will be on the account settings. But if you want to explicitly also test the testing controls that is available on a sandbox account, you do need to log out of the production account and log in into the sandbox account. But it will work seamlessly. Well, challenge question for you is how do you test in TestFlight a paid app, like transitioning from a paid app to freemium? Like, does that really know what I mean? What you can test in TestFlight. Sorry, go ahead. I was going to say is TestFlight is not going to be testing the purchases, but at least you can see which version you're on. And if you want to make sure you're actually reading those API keys correctly, you kind of get a sense. And I guess you could go from your App Store version. You could have one account that downloads the App Store version and then upgrades to the freemium version that they're testing. So that's probably what they'd want to look at. It's going from the paid version that's on the App Store. And I think I want to call out that TestFlight is not the only place you can do sandbox testing. As Sherwood was mentioning, at App Store Connect, you can also create sandbox accounts that you can set up in different countries and reset their purchases and all sorts of more complex sandbox management. And so you can do that as well to test all these kinds of in-app purchase features as you're beginning to step into this new world from a purchase app into a free name app. Okay. So Hello Universe Help, which we'll see, asks again, what's the best way to learn the step-by-step procedure to publish your first iOS app? This is a question we get at WWDC and in labs is just give me an overview. Like I want to just know where to start and what to do and how to do this in the best way. Perfect. Maybe we should start with how an app gets created. Then I can go into test flight and we can go around like app review and go around it. Well, I mean. What's the best way to learn? Okay. So, like, you know, I think what's great is the developer website has a lot of great tutorials and things you can do from, you know, there's videos, documentation, there's WWDC sessions. It's not just this year's WWDC that has useful information. You can go back and, you know, look at them and see what's there. In fact, I was watching one of the videos today and they referenced a WWDC session from 2022. So, like, a lot of this stuff is still great. And then the App Store Connect Help Guide does have step-by-step instructions on how to navigate the App Store Connect UI and what to do. So I really think that we provide a lot of, you know, a lot of our friends here are writing great documentation and the videos to really help you on your way. And that's where I would start. And then specifically, there's an Apple developer pathway that you can follow, which is like a step-by-step way of getting your app on the store for the very first time. And I'll plug the guides again. We have incredibly detailed guides for every single page, every single action that you might want to take. And it's organized in a very nice way to take you from the beginning to the very end. And so I would take a look at those resources. They're all on developer.apple.com. Yeah. Yeah. And there is a Getting Started with TestFlight tech talk, which you can watch, which will actually walk you over, like how do you build an app? How do you test with TestFlight? Yeah, and then you can submit to app review. And once it's approved, wow, it's in the app store. Okay, so once it's approved, Rustam06 asks, how can I increase visibility for my app? Perfect. This is a good one. I would say. Creative assets. You can go ahead and market your app based on not just the... Definitely provide more screenshots, previews, and creative assets so that your app content is visible for everybody to be able to see what is actually your app can help with. Yeah, and we have actually a lot of different tools that you can use to try to get more visibility on the App Store organically. So one thing you can do is create in-app events. You can have custom product pages and tie those custom product pages to specific keywords to try to increase the relevance. You can also submit, do a feature nomination where you take your app and you submit it to our editorial team. And they'll take a look. And if they really like what your app is about, they'll put it on the Today tab and in other parts of the App Store. And that can really give you a huge boost and get your users and your app going. Yeah. And if your app is app of the day or game of the day, there is also with an App Store Connect app, you get a card where you can actually go ahead and share it in the thing, which we call it a shareable moment, and you can advertise it. Through that, you can basically get more users and more visibility of your app. Those same, for what it's worth, you also can create a shareable moment when you have a new version of an app and share that. A lot of what you're going to want to do is off the App Store as well and referencing people back to the App Store. I have a question I already know I want to ask Lydia. Jeff Bash says, I want to develop a universal app. Do I need a different binary for every platform, watch, iOS, et cetera, et cetera? Oh, that's a good question. So if I have a universal app, just all my platforms, one bundle ID, how many binaries do I need? I don't think you need the full set. It depends on which platforms you want to distribute to. And it also depends if your app is eligible for Apple Silicon, et cetera. You can get some platform usage based on that. So you do want to have distinct metadata for each platform. And at least like an iOS binary, a macOS binary, watchOS as well. The iOS watch combo. You can also start with one and add the others as you're ready. Yeah, for sure. That's why you don't need the full set. You can take baby steps. And like you said, more specifically, if you have the iOS app, you can start off by making that available on macOS or on visionOS. Yeah, same. - And once you've done that and you decide, actually I wanna take use of more of the native features and create a vision OS specific or Mac OS specific one, you can do that and your users will just update to that latest one, which then becomes a native version that can rev independently from your iOS and your iPadOS apps. - Yeah, so I feel like this is a hard one to answer. Do I need a different binary? - It depends. - It depends. Definitely, like, it's great to start with an iOS app. And then because there's so many of these expansion capabilities on macOS and on visionOS, and then try those out and see kind of, you know, how it's working there. Yep. So, okay. Okay, Lee Shuang Kwan asks, if an app is localized to multiple languages, for review notes, would it still be recommended to put those notes in English? Or could it be the developer's native language? That is a tricky question. It can be. AppReview has a huge set of language skills. It doesn't mean that there's a 100% match for what your primary language is. But there's often a good chance that if your primary language is not English, that we'll be able to match a reviewer's skills. to that language and review it in that. It may not hurt if you put them in English, but it's definitely not an absolute requirement. Our reviewers do take care of different languages. Yes. I know for a fact that they review apps in many different languages. Yeah. So English could be preferred, but we would support all the options. Right. Yeah. Developers do not need to speak English. On the app store. Okay. E. Dorphy is back with more API questions. What new App Store Connect workflows introduced this year should developers revisit, even if they already have mature automation in place? So one thought. So obviously this person is very focused on automation and the API, which might mean that they're not looking at the dashboard as much. We have a lot of new stuff in App Store Connect Web, in particular on the analytics side. We just launched over 100 new metrics to help developers understand their subscription business, their in-app purchase business. And while that data is available in the API, we have great visualizations that we just released in the web UI. And so if that's of interest to you, I would take a look at that. That wouldn't be in any of the automations. Yeah, I think to answer some of those other ones, the Game Center entities, leaderboards, and so forth can now be submitted. In-app purchases, as we mentioned before, the way that the APIs interact with that will evolve. Yeah, offer code APIs, which is now available for both consumables and non-consumables. Yeah, it's hard, Edorfi. I want to know what Edorfi is really seeking to do. Like what are the best things it depends it depends on if you're a game if you have if you're doing subscription management with this I think the build delivery API last year was a big one that developers who already had automation could take advantage of to Update their build trains and be using that for build submission instead of transport if they wanted to So there's a lot that could be done. I feel like we've given some good advice test flight feedback also Okay All right. Artuk asks, what are the most common reasons to be rejected on the App Store? I think generally it's not. Some of the most common rejection reasons have to do with not being fully prepared for app review. So again, to be a little bit repetitive, but bugs and crashes, so make sure you've thoroughly tested your version before you've submitted it, as a user would on a device, not just in simulator. Also making sure you've provided complete information, and it's been mentioned a couple of times, any demo credentials, any functionality you want to highlight to AppReview and the AppReview notes, taking advantage of where it makes sense for, make sure you've thoroughly tested via test flight internal, following on with external, and gotten that feedback to refine your app to be ready for app review submission. And then just try to make sure your submission is complete and detailed. And then if questions arise from app review or you are dealing with things, that feedback loop can be pretty quick and just be conversational with AppReview and definitely answer any questions they have and test any bug fixes you may need before that. But also feel free to be conversational in your response, like ask questions about if you think they may be seeing something that you're not seeing to help guide them for a successful submission. And another thing is the app review guidelines, there's a lot there. And there are some specific sections for specific types of apps. And so if you're a kid's app, for example, there are going to be extra things that you need to make sure that you do. And so as app review goes through, if they see that your category is kids ages four plus, they will take a closer look at that. If you have crypto or other, you know, content in there where there are specific sections in the guidelines related to that, make sure that you look at those and, you know, hit those guidelines before you submit. One thing Jeff referenced, too, is that we're seeing so many solo developers, so many new people becoming developers, and they can do so much at desk by themselves. But when it comes to testing, sometimes you really need your friends. And, like, you need to cover more corner cases and just besides simulator and your own device. So you'd be surprised, like, a lot of common rejections are just around maybe where a little bit more testing could have helped. So I feel like that's one of the big things if you, you know, if you're worried about app review, like, have you had a few different people test your app to make sure it's working? It launches and that they can use it. I was going to say that Xcode Simulator is great. It's really good. But it's not the same thing. It's just getting on the device, you know, multiple different ones. Talk to your friends. Talk to your family. Use TestFlight. Public links is there. Okay. This is an exciting one because I feel like I have this request too. Nanachi says, What app metadata or capability changes are known to be validated only after TestFlight or App Store Connect upload? Are there plans to bring more of those checks into Xcode or local pre-upload validation? Lydia. We validate all the things all throughout the pipeline. And we're always looking at ways we can get feedback as early as possible to the developer. So we're continuing to iterate. But, yes, I can't list all the validations. Because there are a lot. But, yes, we do want to let you know as soon as possible. We're always looking to, if there's something we could detect earlier and let you know earlier, we make every attempt to do that. Yes, yes. Yeah, at least the warnings are extremely helpful. It's not always it has to be an error that is telling you this is, but it also gives you a list of warnings on what all you should be acting on before you do the next upload. And I can't remember if it was in your question. Also, in Xcode, you can validate your app before delivery. So there are ways that you can get signal before you actually upload the app, which is worth considering. Yeah, I think I understand the spirit of the question. I think we're always trying to move things further up in the development workflow, further back. Earlier. Earlier. Earlier. So there's probably more that could be done. Yeah. But also uploading frequently, like continuous delivery is great for a reason. And like that's a great way to figure out what issues you need to resolve. Okay. Jonathan889 asks, is there a way to organize test flight builds into streams or groups? For example, keeping separate a major new feature that is being developed over months while regular builds continue? Yes, of course. You have the concept of groups in both the internal as well as external. So what is a group? Just to go into some more details of it, right? It's an organization of who are all the testers and what builds goes into it. So those testers who are belonging to a group will only have access to the builds that are within that group. So you decide based on your use case, how many groups do you want to have? Who are the testers in each of these groups? And what builds goes into these groups? For example, there can be a development team. There can be a group. And there can be a QA team. There can be a localization team. And you can have like power user team. Another way to organize this is to say, like, you have an upcoming feature that you're working on, and that could belong to one of the groups where you're working on 2.0 version and building new features for it. And there is also a bug fix release that you're working on, and you want to get immediate feedback because you want to go fix it if possible. Create a separate group for the bug fix release, put the builds in and those testers, so that you can permanently test multiple iterations of your apps that is going in. So you decide. You don't have to upload just 2.0 every time. You can be uploading your 2.0 and then do your 1.1 bug fix at the same time. And in this case, I guess, when they're thinking about this future thing, then maybe it's their 3.0 while they're working on the 1s and the 2s. And that will be its own group. So groups are the best ways to go ahead and have parallel development happening. And you can decide how many parallel development you want to go ahead and support in a given time. And there's a lot that Testlight can do. but also a big part of this is versioning, which is very personal to what the developer wants to do and source code management and having notes and everything there about what these different trains are for. But then once it gets into TestFlight, like Dave said, you can do it in any order. And then from there, you're taking and selecting and matching those to the right group so you want to receive them. Yeah, Xcode Cloud is another way where you can actually automate all of this process so that you can basically take your GitHub, have different branches if you're working on 2.0 and 1.5, and you can set them up to basically distribute automatically to these groups so it all can be fully automated with Xcode Cloud. Yeah, and ties that back to your branch management. Okay. Justin from Baldwinville says, is there a technical or policy reason that there is a few-day delay on price changes to in-app purchases or subscriptions, including when lowering the price? This is a good question. Yeah, you know, this really gets down to we want the price to go live everywhere at the same time and just based off the way the earth turns and the sun rises. It's all about like setting it up so that it can go live at the same time. So we're trying to, you know, give time for that to propagate and then give time so like it's can can match those time zones across the world. Yep. OK. All right. Another very good one. Do you have any advice for merging app listings that target different countries into one app listing? We heard this before with our iOS versus macOS app. Where the builds are, validations of the same, oh, sorry, variations of the same core app, but features differ slightly by country. So they have, I've seen this before, where you have your U.S. app and your Japan app. and the features are slightly different, and you've decided this is a lot to submit all these different builds, and now they need to come together, and what should you do? How do you do that? Yeah, I really think you choose the app you want to persist and keep around. For those paying attention, we did this ourselves this year at Apple with Creator Studio. We used to figure out which of these ones we wanted to keep around, like with our numbers, I think, and pages, right? And we used to have that too. And we understand what it takes. And you pick the app that you want to kind of be that flagship app and update your other one and send a note to them saying, hey, go download this other app and notify your users that this is happening. And then they transfer on over. Yeah, the other thing is we do see this quite a bit with third-party developers too who make a different choice, whether it's branding or platforms, and they need to send a final release that tells users that the app is going away. At that time, they need to have the new app ready to send them to and then give the users a little bit of time to move over before eventually no longer supporting that app and doing kind of a forced upgrade situation. Correct. I think it's good to, you know, I wouldn't throw away that old code right away. You never know what you're going to want to do, maybe a security update or maybe a small bug fix and help those users who haven't quite, you know, upgrade. It's going to take some time. Yeah. Humans are creatures of habit, and I think it's not going to happen overnight. And you can actually see how people are propagating over with the analytics that we provide. So you can see sessions by app version and compare and see, you know, how people are migrating over. Okay, I'm excited about this one. S. McCoy says, the new App Store dashboard with analytics sounds really interesting. And Nick's already referenced it today. Can you tell me more about the features provided and how to maximize value? This was a huge spring release for us, and maybe not everybody knows about it yet. Yeah. So we released the biggest update to App Analytics since it launched over 10 years ago. we added over 100 new metrics, mostly around in-app purchase and subscriptions. And what we did was we made sure that any data coming from the App Store in terms of search or downloads coming from App Store, browse in the Today tab could be tied back to those subscriptions that users might be able to purchase later on. And so what you can see is the full customer journey from download all the way through to purchase and then through to subscription renewal. And we've got these great visualizations that allow you to see what percentage of people who download convert to paid, what percentage of people who convert to paid then continue paying over time. And it's a great way to understand what the soft spots are in your business, and then you can target those with improvements. On top of that, we also released new benchmarks And so as you're looking at that full customer journey, you can see whether you're overperforming or underperforming in certain areas and then take advantage of some of the features that we offer to try to improve. So really big update. If you're a subscription app or an app using in-app purchase, this one's for you. We have a brand new guide as well that goes into detail with images. We have a video. So tons of resources. We're super excited about it. And what we've been hearing so far is developers are loving it. Yeah, and developers, especially the new benchmarks are exciting. We've had benchmarks for a while, and that continues to be a really beloved developer feature because some developers go in and they see the data in app analytics, but they might not know it's as good. Exactly. And oftentimes we tell developers to start with the benchmarks because it's hard to know where you do need to improve. And by looking at the benchmarks, you kind of have a roadmap of what you want to focus on next. So, yeah, great question. Okay. All right. Drummer says, any tips for creating a successful featuring nomination submission? So if somebody wants to get featured, they want to ensure the best chance. What I would say is, first of all, your app should be interesting and potentially novel or do something new that we haven't seen before. There are lots of categories that are pretty crowded. And so those are probably be a little bit less likely to get nominated just because there's a lot of them like that. The other thing I would say is if you have great art, that can be a great way to separate yourself from the crowd. We've released a whole bunch of new assets that you can place on your product page that would also be used in your featuring placement. And we want the app store to look great. And so if you have great art and a great, interesting app, that is the best way to make it to the top of that featuring nomination list. And, you know, you can try a couple times as well. So if you don't get it once, you can try again. But, yeah, those are some tips. And it's not just for the first launch of your app, right? You know, feature nominations, it's a place to talk about updates as well and what's coming and, you know, roadmap. So I agree with you. It's not just all about, oh, I didn't get this first launch out there. Absolutely. Looking at the new updates. I think also it's like about the story behind your app, like a little bit more about the history of how it came to be or what's really interesting about that. Definitely. Sometimes, you know, featuring is about a developer themselves. So that part's cool. Okay. All right. Oh, okay. Robinin says, my apps users paste their own ASC API keys in. Today, even the minimum role over grants, there's no read-only, analytics-only scope, but for all apps. What's the current least privileged setup you'd recommend for a third-party tool? So I think it's a funny question because what is least privilege probably depends on who you are and what it is that's interesting to you. I would probably say the sales role has the lowest level of functions. For what they're describing. Exactly. It's going to give you that kind of thing where you can't make the changes I think they're worried about. But it definitely depends on the role that you're looking to do. Maybe we can talk a little about what the different roles are. Yeah. There is a developer role using which you can upload bills and you can use internal test flight. So that's something that if you want to looking for only uploading and testing, then developer role is something that you can use. Yeah, and the developer and marketer role can do things, but they can't release your app or release a new version. Like on the marketing role, you can make changes to the metadata, the product page, end up events, and those kinds of things. So if that's the role you want to give with this key for API, that's what you're looking for. So those would be probably the lower permission recommendations we would make. Okay. Another one from D Robinin, any advice on fetching live or last 24 hours of App Store Connect data via the API? Currently there is no API versus UI parity. So while the UI we can preview last 24 hours worth of data via the API, we can fetch only a day before or get weekly or monthly aggregates. I don't know that much about this. Yeah. Well, they're, I mean, they're right. You can see the last 24 hours in the UI in sales and trends, and the API updates on a daily basis. And so if they do want the latest and greatest, which it sounds like they want, the UI is the place to do that. But understood that it seems like this developer would like to see faster data in the API, but currently not possible. It is the same data. It's just a different cadence depends on how you're acquiring it. And I know it's kind of implied in the question, but we're talking really here about the sales data. We're not talking about, like, other data in App Store Connect that's all updated, whether it's the rest of that is all pretty much piecemeal. But when we're talking about the analytics or the sales and trends, that's what's getting. Good clarification. Summarized. 100%. Nick, you're going to get hit a lot because we have a lot of questions about app analytics. Okay. Edward Kwong asks, what's your recommendation to measure the incremental impact, visibility, and downloads from creating the organic search CPP, especially when we don't get keyword level data in ASC? Is that true? It is true. We don't provide keyword level data in ASC. But what I would say is if you're creating a custom product page, you can go into App Analytics and you can see how well that's performing overall. But then you also have the ability to add a filter by source type. And so what you can do there is filter by App Store search and take a look at how that's doing. If you're not running any ads through Apple Ads, then that App Store search will just be your organic search. If you are running ads, then it will be blended together. But you could consider having two custom product pages, one for ads and then one for organic, so that you can tease out the difference there. okay i'll give you a break jonathan 889 asks is there a way to see the rollout progress of the current release while a new release is being prepared and submitted to review so this is we could we could assume that they're using phased release if they're talking about the rollout of the current release yeah that's what it sounds like to me uh and so you can in app connect you can go in to the version page and then click into phased release rollout and it you know shows you what you know what current day you're on where you are in this phase release rollout cycle yeah you just click on your prepare for distribution version yeah to see it because you can have up to two versions in App Store Connect per platform you've got the the one that's you know ready for distribution that's out there and then you can you know start working on other version so it sounds like what they're talking about here is while they're working on their their new version what's the state of that uh phased release for the other one okay i think we have time for one more lewis courtney asks i'm making a geospatial augmented reality game about shakespeare and stratford upon avon i'm in already building a full working demo version of it for app submission will be incredibly difficult, if not impossible. What options are open to developers building geospatial experiences in terms of passing app review? So wait, do you need to be in Stratford-upon-Avon? That's my question. Maybe. To review the app. To take advantage of the app. Is that the demo that's needed? If it's something where the review would need to take place in a specific location, then you can absolutely include a recording of your app with your submission. Yes. But keep in mind that, you know, that, you know, not all of your users, even those who occasionally visit Stratford-upon-Avon like me, will be there all the time, and you do want to provide some functionality for those who, you know, currently reside outside the UK. Yeah. And this is where the whole ecosystem helps, right? Like, yes, build your app, test it with TestFlight, Once you're ready with internal test flight, move on to external test flight. And that will help you to pass the app review eventually because you're going through a bit app review process. It gives you insights into what your geo experiences of the app is and is app review okay with it. So early feedback is always good and that helps. I'm going to be looking out for this game though. Yes. And I hope that you can play it outside of Stratford upon Yvonne so that I can play it. So thank you everyone so much. We're out of time. Thank you for all these incredible, thoughtful questions. If we didn't get to your question, there's still a chance. You can go to the Apple Developer Forums at developer.apple.com slash forums. We also love feedback. And so if you have feedback or feature requests, there are some great feature requests in these questions. You can go to feedbackassistant.apple.com. My team looks at those every single week. We go through every single piece of feedback that comes in. can't emphasize that enough. Yes, we really do. So please submit feedback and I assure you that we're taking that into thoughtful consideration as we build all these incredible products. And thank you to my amazing panel. Shout out to our back of house staff who's helping us be successful today and have an amazing WWDC and hopefully we'll see you on the App Store.