App Review

RSS for tag

Understand the technical and content review process for submitting apps to the App Store.

App Review Documentation

Posts under App Review subtopic

Post

Replies

Boosts

Views

Activity

Preventing Copycat and Impersonation Rejections
In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.
0
0
1.6k
4w
Your app still allows users to purchase physical goods or services using the in-app purchase API.
Hi everyone, I’m looking for some help or clarification regarding repeated rejections under Guideline 3.1.3 - Business - Payments - Other Purchase Methods. In earlier versions of our app we did experiment with using in-app purchases for our eSIM-related service (which App Review treats as a physical good/service). After the first rejections, we fully reworked the payment flow. In the current build we have: Completely removed any use of the in-app purchase API / StoreKit and removed all UI elements and wording mention in-app purchases. Detached all in-app purchase products and marked all previously created IAP products as “removed from sale”, so they are no longer available to users. Moved all payments to an external outside of the in-app purchase API, which (as I understand it) is exactly what Guideline 3.1.3 requires for physical goods/services. Despite this, the app is still being rejected with the same 3.1.3 message about using in-app purchases for physical goods, without any new details or updated screenshots that point to the actual problem in the latest build. One thing that might be related: in App Store Connect there are still some legacy in-app purchase products stuck in an “In Review” state. We can’t delete or fully edit them from our side, even after removing the previous builds. They are not attached to the current version and are not referenced anywhere in the code or UI, but I’m worried they might still be confusing the review process. Has anyone run into a similar situation? Can these legacy IAP products in “In Review” status still trigger 3.1.3 rejections, even if they’re not attached to the binary and removed from sale? Is there any way to get App Review or Developer Support to reset or clear these products so we can fully remove them? We’re a small team trying to launch, and at this point we feel a bit stuck in a loop where the feedback doesn’t seem to reflect the current implementation. Thanks in advance for any help or insight.
0
0
17
9h
Confused by Rejection – Physical QR Purchase Already Moved to Stripe (Not IAP)
Hi everyone, We just received another App Store rejection under Guideline 3.1.3 - Business - Payments - Other Purchase Methods, stating that we are using in-app purchases to sell physical goods — specifically, a physical QR code sent to the user. However, in our latest build, this issue was already addressed: All physical QR code purchases are now handled entirely through Stripe Checkout, outside of the app. No consumable IAPs are used for physical goods. The purchase flow is completely optional - users can tap “Continue” to skip it and still use the app without ever engaging with Stripe or purchasing anything physical. We’re a small team trying to launch and are stuck in a loop where it seems like the rejection feedback might not reflect the latest build with not clear feedback from Apple. Has anyone experienced something similar? Would really appreciate any guidance or insight — or if anyone from Apple is here, we’re happy to jump on a call to clarify. Thanks in advance!
2
0
169
9h
Getting update pushed out after resolving app review issue
Hello, I submitted a small update to my app two days ago, and the update got rejected early yesterday because of a small issue in the metadata. I promptly fixed the issue and replied to app review saying so. It has now been a little less than a day since then, and the update still hasn't gotten processed. Ordinarily, I wouldn't be in such a rush, but I have a really important app-related event tomorrow. Is there anything else I have to do for the update, or is it good to go now that I've fixed the metadata?
1
0
14
10h
Allowed method for using Stripe in a mobile app for purchasing subscription plans?
Hello, I need clarification about the correct and allowed way to use Stripe inside my mobile app for subscription purchases. My mobile app is for real estate agents. An agent can create an account and gets unlimited property uploads for the first 3 months. After 3 months, they must choose a subscription plan: Basic Plan: 3 property uploads per month Premium Plan: 15 property uploads per month The same agent can also log in on my website, where I am using Stripe to handle subscription payments. From the website, they can upgrade or downgrade their subscription. Now the main question: I want the agent to be able to upgrade their subscription directly from the mobile app as well, using Stripe. What is the allowed and compliant method to let the user purchase or manage their subscription inside the mobile app, considering that Stripe is used on my website? Specifically: Can I open a Stripe Checkout page in a WebView? Or must I open it in the device’s external browser (Safari)? Or does Apple require a different approach? Is there any officially allowed workaround so that I can safely use Stripe in the mobile app for subscription updates without risking App Store rejection? I simply want to follow the guidelines correctly and avoid any issues during review. Thank you
1
0
15
10h
Is it allowed to include an additional executable inside a macOS App Store app bundle and let users run it manually?
Hello, I’m preparing a macOS app for App Store submission, and I have a question regarding whether including an extra executable inside the app bundle is permitted under the App Store Review Guidelines. My app would include a command-line tool placed inside the bundle, such as: MyApp.app/Contents/MacOS/ or MyApp.app/Contents/Resources/ The purpose of this tool is to help users collect hardware/system information for troubleshooting or error reporting. Importantly: The app never launches this executable automatically. It never runs in the background. It is intended to run only when the user chooses to run it manually. The intended workflow is: The executable is shipped inside the app bundle. When needed, the app simply informs the user where the tool is located. The user manually executes it—either by double-clicking in Finder or by running it from Terminal. The executable runs independently, and the app does not trigger, spawn, or control the process. My questions are: Is this approach allowed under the macOS App Store Review Guidelines? Could this be considered “executing external code,” a sandbox violation, or otherwise lead to rejection during App Review? Does App Review allow a tool that is bundled with the app but executed manually by the user outside of the app itself? Additionally, if there is any official documentation or guideline from Apple that specifically addresses this scenario—or similar restrictions around including executables inside a macOS App Store app bundle—I would greatly appreciate a link. If anyone has experience with this or knows how App Review typically handles this type of setup, I’d be grateful for any insight. Thank you!
1
0
18
10h
In-App Purchase Continuous Rejection
Dear Reviewers/Apple Team/Community, We have trying to submit our app continuously for review and being rejected continuously by Apple. Our app works perfectly fine in TestFlight using the same ID apple is using. We have also provided recorded video of the testing in TestFlight to Apple reviewer. However, despite our requests below things are not done: Before testing the in-app purchase subscription are not being approved, despite us requesting the same every time during submissions. At times we are getting snapshots under error category, where everything is correct even from Apple testing. We have no other way but to explain, give snapshots, give videos to Apple to help them understand how to test the app. We have requested the reviewers multiple times for a call, but we got a call only 1 time. We are not sure what is the way we can get to talk with the reviewer and understand from them the issue they are facing. Can anyone please help us out? Below is one example, it was given it us under error category, where even with apple standard, the purchase is successful. Can someone help us out plz.
1
0
374
1d
Can I use PermissionKit to request parental consent for a minor accessing features other than chat?
In iOS 26.2, PermissionKit allows apps to request parental consent when a minor attempts to initiate a chat function. I believe this feature would be extremely useful when a minor tries to access other features in an application. For instance, in a real-time streaming service, when a minor attempts to access certain content, I would like to require parental permission. Is it acceptable to use the currently provided PermissionKit to send a request to the parent in this scenario? I am considering providing arbitrary values or nil for the action and PersonInformation parameters in this case. I would appreciate it if a fellow developer or an Apple staff member could confirm the intended scope of PermissionKit and if this kind of non-chat-related use case is permissible.
1
0
60
1d
My apps have been deleted
A month ago, a company filed a false complaint against one of my apps. I contacted Apple and informed them that this was untrue, uploading videos and screenshots proving that my account and apps comply with Apple's policies and that the complaint was baseless. Despite this, I was surprised to find all my apps deleted and my account flagged for deletion in the following days. What should I do? I've been wronged, and I've submitted numerous complaints and contacted technical support by phone and email, but so far, I haven't received any response or attention.
1
0
34
1d
Desperate with constant Guideline 1.1 Rejection and possible unfair treatment
Hi everyone, I am really not sure where else to go for a piece of mind because our recent review experience has been far from clear (and probably fair). We are a photo editing app developers who deal with AI models, effects and transformations on a constant basis. I believe last year we (like many other apps in the category) introduced effects that get two people in different photos and unite them in one cute/fun/cozy/emotional picture. Be it a couple, a mother and daughter - you name it. Of course all the templates are pre-set, there is no option for users to generate any scene by text-to-image or image-to-image model. Otherwise it would be unsafe. When submitting our app to review in May, 2025 we first faced the situation that this kind of effects are not welcome because of: Guideline 1.1 - Safety - Objectionable Content The app references or includes features that some users may find objectionable or could be used to create objectionable content. Specifically: The app includes templates for generating content showing people making intimate contact with each other, such as hugging, kissing, or other intimate templates. While these templates alone may not be objectionable, they could be used to create objectionable content. Apps on the App Store should be safe, appropriate for a general audience, and should not include features that are objectionable or could be used to create objectionable content. At that first time we saw it as new general requirement and rule and complied. It took us about a month to delete the "objectionable" content and finally get approved. Time passed and what we saw in the middle of summer was ALL the huge players in the market kept providing these "objectionable content" freely, both inside apps and as store graphics. So we re-added the content, submitted, and get approved like immediately. Was it a miracle or a matter of a particular reviewer, I cannot say, however after that we didn't get any reject for months. Then around October we submitted our app for another review and history repeated itself - same reject as in May for the same reason. Nothing helps us to get through. Nothing. 5-6 appeals about the review and 1-2 about unfair treatment, no response. Did I mention that all the huge players (like 5-6 apps) keep posting the same content freely? All of them released updates for Christmas last week with Group Photos / Shared shots / Photobooth Lab featuring exactly the same 1+1=united pic concept. Our latest appeal gets reply however, all the same: We understand your position and consideration of your app's compliance with Guideline 1.1. However, we found that the app references or includes features that some users may find objectionable or could be used to create objectionable content. The app includes templates for generating content showing people making intimate contact with each other, such as hugging, kissing, or other intimate templates. While these templates alone may not be objectionable, they could be used to create objectionable content. The strange thing is the screenshot attached wasn't even connected to the case itself, it was of a filter that was applied to photo that already contained two people. I don't see any logic in the responses any more: Not only the Guideline 1.1 - Safety - Objectionable Content quotes anything about the mentioned reasons for rejection. We have carefully reviewed the entire text of Guideline 1.1, including sections 1.1.1 through 1.1.7, and we are still unable to determine which specific part of the guideline the rejected templates violate. The note states that our “couple effects” (hugging, close poses, romantic themes) could be used to create objectionable content. However, when mapped against the text of Guideline 1.1, none of the listed categories appear to apply: The effects are not defamatory, discriminatory, or mean-spirited (1.1.1) They do not depict violence, harm, or abuse (1.1.2) They do not involve weapons or illegal activity (1.1.3) They do not contain sexual or pornographic material, nor explicit activity (1.1.4) They do not involve inflammatory religious commentary (1.1.5) They do not supply false information or trick functionality (1.1.6) They do not capitalize on harmful current events (1.1.7) And so on. As reply for our "Why other apps are allowed to have this content while we don't?" they returned with this: On occasion, there may be apps on the App Store that don't appear to be in compliance with the App Store Review Guidelines. We work hard to ensure that the apps on the App Store are in compliance, and we try to identify any apps currently on the App Store that may not be. It takes time to identify these occurrences, but another app being out of compliance is not a reason for your app to be. It has been 6 months since our first instance on the matter. None of the competitors removed such content from their apps while we are constantly being forced to do so. Does this imply them having another review experience? Or do they hide the mentioned features before review and get them back right after? It's a mystery... I will really appreciate any advice on how we should deal with this matter. Thank you in advance
1
0
35
1d
Repeated rejection for Guideline 3.1.2 – Privacy Policy & EULA links present, but review still says missing
Hi everyone, I’m currently stuck with repeated App Store rejections under Guideline 3.1.2 (Subscriptions) and I honestly don’t know what else I can change. Apple keeps stating that the Privacy Policy link and Terms of Use (EULA) are missing from the app metadata. However, to the best of my knowledge, everything is already in place: The Privacy Policy link is: ✅ added in the Privacy Policy field in App Store Connect ✅ shown on the paywall ✅ accessible inside the app ✅ included in the app description The Terms of Use (Apple Standard EULA) are: ✅ linked in the app description ✅ shown on the paywall ✅ accessible inside the app This setup has been in place for multiple submissions, yet the app continues to be rejected with the same message saying these links are missing. At this point, I’m unsure: whether Apple expects the links in a very specific field or screen whether the reviewer is checking a different location or if I’m misunderstanding where exactly Apple requires these links to be present Has anyone experienced something similar or knows the exact place Apple checks for Privacy Policy and EULA links for auto-renewable subscriptions? Any clarification would be greatly appreciated, as I’m currently completely stuck. Thanks in advance!
1
0
33
1d
in-app won't pass review for unknown reason
Hi, I am trying to get an app approved. In app purchases say that I need to fix something without saying what needs fixing. I can't add the in-app purchases to the app review and that one does not pass because there are in-app purchases missing. How can I fix this issue? I assume that during review someone could just write whats missing but obviously they won't. The message I received said: One or more of your In-App Purchases has been returned for the following app: Literally nothing else. Regards,
1
0
35
1d
Seeking clarity for pending termination for Apple Developer Membership
Hi all, It has been >30 days since my app was removed, and I was served with the pending account termination notice. Similar to others, I was flagged for section 3.2(f). Submitted an appeal, explicitly addressing every possible violation, offered to show source code with entire history, and also have all the email threads of me providing customer support to my users, and also multiple 5 star reviews. However, I was met with the rejection and the confirmation that the account would be terminated. Fast forward more than 30 days, my account is still here, but no closure or clarification at all regarding what I can do moving forward. Understandably, the team deals with millions of submissions and apps, but isn’t it reasonable (given that we pay $100/yr) to at least get some clarification on what went wrong? Currently, all I want to know is, Can I create a new account and develop other apps? Or will I risk getting banned again, hence wasting another $100? If I am able to proceed, what do I need to do to make sure my app doesn’t get randomly terminated again? Why aren’t there any signs or warnings? If anyone is able to assist me on this, I would greatly appreciate it. Thank you so much!
0
0
50
1d
Stuck in "Waiting for Review"
My app's Custom Product Page (CPP) submission has been stuck in "Waiting for Review" since its initial submission on November 28th, for over two weeks now. Key Timeline and Troubleshooting: Initial Wait and Self-Check: Initially thought it was a normal queue, but there was no progress after several days. Comprehensive Troubleshooting: I have confirmed: Developer account agreements and tax status are normal/valid. This CPP is associated only with the live, published version of the app and is not linked to any pending new version. There are no "Issues to Resolve" prompts in the App Store Connect backend. Attempted Standard Solutions: I have tried "Withdraw and Resubmit" multiple times. The operation completes successfully, but the status always reverts to "Waiting for Review" and never progresses to "In Review". Contacted Official Support: I have reported this issue multiple times through the App Store Connect "Contact Us" form and via email, explaining the suspected technical fault. However, I have not received any substantive feedback. My Core Question: Could this possibly indicate that my account or this specific CPP submission has encountered some rare "lock" or data synchronization failure within the backend system?
2
0
163
2d
I’m desperate…
Hello everyone, I’ll be honest with you, the kind of honesty that comes when you’ve run out of places to turn. My name is Donovan, I’m a French student, and I’m writing here because at this point, I truly don’t know what else to do Two years ago, I started a small project to learn mobile development. Nothing ambitious at first just a personal exercise, a way to grow. But after countless late nights, weekends sacrificed, and lines of code no one will ever see… that small project became a real application. I finished it. Refined it. Carried it like something that genuinely mattered. And for the past two months, I’ve been fighting with App Review. Always for the same reason: Guideline 4.3(b) – Design – Spam. Each time, I respond. Each time, I explain. But each time, the door closes with the same cold, impersonal message: “We encourage you to reconsider your app concept and submit a new app that provides a unique experience not already found on the App Store.” Unique. Such an easy word to use… especially when no one seems willing to look closely at what’s actually in front of them. My application is a dating app, yes. I know there are many on the App Store. But I implemented a feature that no other dating app currently provides, and more importantly: the app is 100% free, no paywallsno mandatory subscription. As far as I know, there is no completely free dating application on the App Store. I even added features that were never planned, just to avoid being dismissed as “spam.” But nothing has changed. Two years of work. Two years of progressing 4–5 hours per week, between classes, exams, and everything else life throws your way. And now, it feels like all of that can be wiped away by a single generic sentence. So here I am, turning to you, the developer community, the only people who truly understand what it means to run into an invisible wall. I need your help. Your advice, your experiences, your strategies. How can I get Apple to finally accept my app? How can I avoid throwing away two year of work because of a vague, unexplained guideline? Thank you in advance to anyone who takes the time to reply
1
0
70
2d
App Store Connect Showing Old Metadata After Updates (Account Termination Appeal APL255848)
Hello everyone, I’m an iOS developer from Türkiye, and I’m currently facing a serious issue regarding my Apple Developer account termination (Appeal Ticket: APL255848). Problem: I have removed all references, icons, descriptions, and metadata related to my previous app name (“Nano Banana”) both inside the app and on the App Store listing. I submitted updated assets, screenshots, and a new metadata package. However, the App Review Board seems to still be seeing old cached metadata, old icons, or previous descriptions that no longer exist in my build. Because of this, every response from App Store Connect repeats the same text, even though I have already made and proven all required changes. Current Situation: My account is terminated, and my appeal has been pending for over 3 weeks with identical non-actionable responses. I am not receiving my revenue for the past 2 months. I want to comply fully with the Apple Developer Program Agreement and provide any documents required (invoices, trademarks, API invoices, technical details, etc.). I believe there may be a metadata caching issue or the review team seeing an older version of my app. My question to the community: Has anyone experienced a case where App Store Connect or the App Review Board continues to see outdated metadata even after everything is updated? Is there a recommended way to ensure Apple sees the latest changes (e.g., waiting for metadata propagation, submitting a blank metadata update, reuploading the build, or another technical step)? Any guidance or similar experiences would be extremely helpful. Thank you in advance. Kind regards, Yunus Emre Özdiyar
1
0
113
2d
运营了一年多app更新的时候一直正在等待审核,然后被标记封号下架了?霸王条款
运营了一年多app,更新了很多版本,这一版更换了下ui的预览图,然后更新的时候一直正在等待审核,等了很多天没有结果,给苹果发了邮件询问,然后被标记封号下架了?请问这个是怎么回事,就是常规更新为什么不审核,然后又下架了?申诉了越没有任何回复邮件,这妥妥的霸王条款, appid:6670458903 串聊 请求苹果公司能开发者给恢复正常更新,谢谢 Pending Termination Notice Upon further review of the activity associated with your Apple Developer Program membership, it's been determined that your membership, or a membership associated with your account, has been used for dishonest or fraudulent activity, in violation of the Apple Developer Program License Agreement. Given the severity of the identified issues, your account has been flagged for removal. Because your account has been flagged for removal, any earnings payments are paused and app transfers are disabled. Creating new accounts after receiving this message may result in the termination of the new or associated accounts. Evidence of Dishonest or Fraudulent Activity App submissions from your account have repeatedly violated the App Review Guidelines in an attempt to evade the review process. After multiple resubmissions, the guideline violation(s) detailed to you in prior correspondence remain unresolved. Guidelines or Terms Violated The dishonest or fraudulent activity described above directly violates section 3.2(f) of the Apple Developer Program License Agreement, which states: "You will not, directly or indirectly, commit any act intended to interfere with any of the Apple Software or Services, the intent of this Agreement, or Apple’s business practices including, but not limited to, taking actions that may hinder the performance or intended use of the App Store, Custom App Distribution, TestFlight, Xcode Cloud, Ad Hoc distribution, or the Program (e.g., submitting fraudulent reviews of Your own Application or any third-party application, choosing a name for Your Application that is substantially similar to the name of a third-party application in order to create consumer confusion, or squatting on application names to prevent legitimate third-party use). Further, You will not engage, or encourage others to engage, in any unlawful, unfair, misleading, fraudulent, improper, or dishonest acts or business practices relating to Your Covered Products or Corresponding Products (e.g., engaging in bait-and-switch pricing, consumer misrepresentation, deceptive business practices, or unfair competition against other developers)." Appeal If you would like to appeal this termination decision to the App Review Board, you must do so within 30 calendar days. When submitting your appeal, be sure to select "I would like to appeal an app rejection or app removal" from the drop-down menu on the Contact the App Review Team page and provide a written statement that includes the following: A thorough explanation of the issues we identified Specific steps you will take to prevent its recurrence New information clarifying these issues, if you disagree with our findings Otherwise, your Apple Developer Program membership will be terminated. If you have questions, contact us.
1
0
218
3d
3.2(f) termination after an update focused on balance, stability, and a small read-only News panel — looking for guidance
Context After our latest update we received a termination notice referencing 3.2(f) (feature/concept switching after review). The update itself included performance/stability improvements, bug fixes, numeric balance tuning, and a small user-initiated News panel (globe icon in the main menu) that displays a single static announcement image and can be closed at any time. There are no links, no navigation, no login/UGC/ads, and no executable content in that panel. We do not collect personal data (no IDFA/ATT). What we’ve done so far Restricted any post-release changes to numeric balance values only. The News panel remains strictly informational (one static image from our own domain with offline fallback). Prepared a short screen recording and code excerpts that demonstrate these constraints. Questions for the community Has anyone faced a 3.2(f) action in a similar scenario (read-only announcement panel)? What clarifications or evidence helped your appeal? Which additional safeguards (domain allow-list, redirect blocking, formal release checklists, etc.) proved most convincing to App Review? Is it helpful to provide a short video (tap globe → panel shows a single image → close) along with code snippets confirming there’s no navigation or executable content? References / Illustrations Main menu and News button: /mnt/data/62591a87-a516-499a-a743-86ace7e9e3a4.png Store creative preview: /mnt/data/337413b0-e5db-466c-bd04-28efa7fb6b52.png News panel mock (single image): /mnt/data/A_screenshot_of_a_mobile_game's_update_news_screen.png Any practical advice or precedents would be greatly appreciated. Thanks in advance!
1
0
102
3d