Press Kit for InspiringApps
Looking for more? If there are additional assets you need but don’t see, please reach out to email@example.com with your request. Thank you!
We Wrote the Book on App Development
Our free book explains the business, marketing, and technical considerations for an app development project, enabling leaders to understand key concepts and make informed decisions on how to best apply technology to business challenges.
Creating an Apple Developer Account
In order to publish apps for Apple’s platforms, you must start by creating an Apple developer account for your organization and setting up permissions. This article walks you through the process. Apple offers both individual and organization accounts. Begin enrollment for both individual and organizations here. We strongly recommend that you enroll as an organization even if you are the only one currently managing your business. This is because enrolling as an organization preserves the opportunity to invite other team members to contribute to your work in the future. In order to enroll as an organization, you’ll need the following: A D-U-N-S NUMBERThe business data company Dun & Bradstreet assigns D-U-N-S numbers to organizations. A D-U-N-S number is a unique nine-digit identifier for businesses. Request a new D-U-N-S number through the Dun & Bradstreet site.Note: Some of our customers find that applying for a D-U-N-S number requires more time than the Apple developer account. If you don’t already have a number, we recommend starting this process as soon as possible. Legal Entity StatusYour organization must be considered a legal entity (e.g. partnership, LLC, corporation, etc.). Legal Binding AuthorityYou must have the legal authority to bind your organization to legal agreements. PaymentYou will need a credit card for payment. After your initial payment, you can set the account to auto-renew each year. We recommend doing so to avoid gaps in your membership that could cause your apps to disappear from the App Store. After your developer account is approved, log into App Store Connect to set up your team. Since you created the account, Apple considers you the sole “account holder” or owner. The account holder must periodically review and accept Apple’s updated Terms and Conditions. The account holder also has the authority to invite other users to help manage other aspects of the app’s store listing. Follow these steps to invite new users: Click the “Users and Access” button from the main dashboard in App Store Connect. Select the add button (blue circle with a “+”) to add a new user. You’ll see the form below. Once added, users will receive invitations from Apple to join your development team. Invitations expire, so it is important to click on the corresponding link to accept the invitation in a timely manner. In the “Roles” section, select “Admin” to allow the user to manage your apps as well as other users (including members of the development team) in your account. If you are not comfortable granting Admin access, “App Manager” is the lowest level role that will still allow app development teams to create new apps for you in your account. Note: For our developers it is important to check the “Access to Certificates, Identifiers & Profiles” box at the lower left of the form unless you or your team is comfortable managing code signing certificates yourself.
Creating an Android Developer Account
In order to publish Android apps to the Google Play App Store, you’ll be creating an Android developer account for your organization and setting up permissions. Follow the steps below to get started. Register for a Google Play developer account here. You will need to use a traditional Google Account (i.e. one that ends in “@gmail.com”). Navigate to the Google Play Console. Here you can review and accept the Google Play Developer Distribution Agreement and pay the one-time registration fee for your account. Fill out your Google Play developer profile and account details. Your developer name will be the name displayed in the Google Play store. Note: it may take up to 48 hours for your payment and registration to be fully processed. After your developer account is approved, you as the account owner can manage the data privileges of contributing team members. This includes granting project access as well as establishing roles and permissions for all contributors. Invited users do not need to pay a registration fee to join the project and use the Developer Console. Follow these steps to invite new users: Log into the Google Play Console to set up your team. Click “Users and permissions” from the left sidebar. Select “Invite new users” on the bottom right. Users will receive an invitation from Google to join your development team after they are added. Invitations expire, so it is important for invitees to click on the corresponding link in a timely manner. Rather than limiting roles to predefined permissions, Google offers account owners fairly fine-grained control of permissions so that they can establish the right level of access for all new users. These options can be manipulated by navigating to the “Account Permissions” tab. Select “Admin (all permissions)” to give users full control of the app. If you are not comfortable granting admin access, you’ll at least want to check these boxes: Play Games Services (if you’ll be publishing games) Releases Store presence
Submit App Privacy Details to Apple
Developers must now provide app privacy details to Apple. In late 2020, Apple introduced new information disclosure requirements to address consumer demand for greater transparency in data usage. This change followed growing concern that developers may be using private data in surprising ways without their customers’ awareness or permission. As a result of Apple’s new privacy requirements, all apps and app updates submitted to the App Store must now include answers to a privacy questionnaire. Follow the steps below to complete the app privacy details questionnaire. In our experience, the questionnaire takes approximately 15-30 minutes to complete. Your legal and development teams will likely need to work together to accurately complete the process. Moreover, collaboration among team members will ensure that your organization obtains the best possible results. Start by navigating to your app in App Store Connect. Click App Privacy in the left sidebar. Select Get Started in the center of the page. You will then be directed to Apple’s definitions of “Collect” and “Third-party partners.” After reviewing this information, answer the following question: Do you or your third-party partners collect data from this app? A No response will make for a short questionnaire; however, this answer is rarely accurate. Most apps collect usage data to inform future decisions regarding app enhancements. If the collection is anonymized and not connected to a particular device, session, or user, then a “No” response may be appropriate. A Yes answer will prompt further inquiry into the types of data that you and your third-party partners collect. As mentioned previously, a Yes response will subsequently require you to provide information on your data collection practices. Apple groups data into the 13 categories below. Be sure to check a box next to each type of data that your app collects. Specific requirements for each category may change. Therefore, please consult the form for further information. Contact Info Health and Fitness Financial Info Location Sensitive Info (for example, race, ethnicity, sexual orientation, pregnancy, etc.) Contacts User Content (this includes emails or text messages, gameplay content, customer support, and more) Browsing History Search History Identifiers (specifically, user ID and device ID) Purchases Usage Data (product interaction, advertising data, etc.) Diagnostics Other Data (i.e. any other data types not mentioned) Now that you’ve selected the data categories that are captured in your app, you can complete the final round of follow-up questions. The following 6 data usage subcategories must be addressed: Third-Party Advertising, such as displaying third-party ads in your app or sharing data with entities who display third-party ads Developer’s Advertising or Marketing, including displaying first-party ads in your app, sending marketing communications directly to your users, or sharing data with entities who will display your ads Analytics—in other words, using data to evaluate user behaviors, including understanding the effectiveness of existing product features, planning new features, or measuring audience size or characteristics Product Personalization, or customizing what the user sees App Functionality, including collecting data to authenticate users, enable features to prevent fraud, and improve scalability and performance (among several others) Other Purposes, meaning any other purpose not listed Depending on the types of data that your app collects, you may be answering well over 100 questions in total. Your responses will then help generate a “security nutrition label” for your app. Apple displays this label with your app in its App Store listing. Consequently, this new requirement aims to help users make informed decisions about their data privacy. After providing answers to all of the questions in the two stages of the questionnaire, you can finally click the Publish button on the main App Privacy page for your app. By making this selection, you’ve finally completed Apple’s privacy details requirement. You’re now ready to submit your app for review.
Testing iOS Apps via TestFlight
You’ll want to begin testing iOS apps via TestFlight before releasing a new or updated digital creation. TestFlight refers to the Apple system and accompanying iOS app that gives testers the ability to evaluate new products. The number and types of users who should have access to your pre-release build will inform how you choose to distribute it in TestFlight. If they don’t already have one, team members will need to create an Apple ID in order to participate in TestFlight processes. The following is a description of TestFlight’s two distribution options: Internal testing is intended for employees of your organization. You can invite up to 100 team members to engage in the process. A key advantage of internal testing is that pre-release builds are not reviewed by Apple after you make them available in App Store Connect. As a result, the time between the final push from the development team and the availability of your app to testers is usually under 30 minutes. A downside to this option is that you need to send two invitations to each internal tester. Internal team members must first accept an invitation to App Store Connect. After receiving this invitation, they must then accept a second TestFlight invitation that gives them access to pre-release builds. External testing is intended for users outside of your organization. This type of testing allows you to make pre-release builds available to thousands of external users. Due to the widespread participation that this option affords, test builds must be reviewed and approved by Apple before they can be shared with external testers. This approval process is as rigorous as Apple’s system for reviewing publicly released Apple products. The requirement therefore adds hours or days to the time between the final push from the development team and a pre-release build’s availability to external testers. External testing is advantageous because it offers greater ease of distribution. External users do not require App Store Connect access. Accordingly, they only need to accept a TestFlight invitation to join the testing process. You can use TestFlight to manage lists of external testers as well as send personal invitations to team members. External testing also gives you the option to grant access to pre-release builds to anyone with a public link. Clients often open up external testing to team members by sending a public link (which is the same for all users) to testers via email or by posting a public link on their website. You may not know who is testing your product, so Apple provides the option to limit the total number of external testers. This feature is valuable if the exact pool of testers is less critical to your product’s pre-release. For example, you may want 1,000 testers to evaluate the latest version of your app before it is made available to millions of users, but you don’t care which 1,000 users test your product. Establishing a limitation on the number of testers is a great way to address scenarios like this one. When evaluating iOS apps via TestFlight, know that these pre-release builds are not publicly available in the App Store. Users must first install TestFlight onto a mobile device. They will then need to accept an invitation URL or enter a redemption code to install a pre-release version of your app in TestFlight. This process is very similar to installing publicly available apps from the App Store.
Testing Android Apps via the Google Play Store
Before a new version of your Android app is made available to the public, you may want users to test it. This article walks you through the process of testing Android apps via the Google Play Store. The Google Play console is used to control access to your pre-released build. By relying on factors such as number of testers and their relationship to your organization to determine access, you can release the best version of your app. Testing tracks provide a way to organize new releases and push them toward public production rollout. Although we recommend using at least one track before release, testing tracks are not technically required and you certainly don’t need to implement all three of them. Below is an overview of each type. Internal testing lets you make your app available to up to 100 internal testers. This option is typically used if you wish to give access to your own employees. Closed Testing Closed testing allows you to establish one or more testing tracks for assessing pre-released versions of your app. When closed testing is employed, users don’t need to be members of your organization but you will need to invite them to participate (more on that below). Closed testing lets you evaluate an initial version of your app before expanding access to a larger group. Open Testing Open testing makes your app available to a large group of testers. When you run this track, anyone on Google Play can opt in to testing without an invitation. Tester Lists When testing Android apps via the Google Play Store, multiple lists of testers can be created for the internal and closed testing tracks. Lists are created according to your preferred means of organization. For example, some clients make lists for each department in their organization while others choose to create one list for employees and another for contractors. The means of organization is entirely up to you. Each member in a list must have a Google email account (i.e. one that ends in “@gmail.com”). If Google manages the email accounts for your organization, then it is acceptable to use your own domain. All users in a list will need to opt in to testing. If they don’t receive an email invitation from Google automatically, you can retrieve the opt in URL from the Google Play console and send it to users via email, SMS, etc. The URL will be the same for all testers. Note: it is best to accept an invitation from an Android device. After opting in, users can access the pre-released app using the same Google Play Store interface that they use to search and install publicly available apps. As long as users have opted in to pre-release testing, they can always see the latest build in Google Play. This version may be more current than the publicly available one. Users can opt out of testing at any time, at which point they will only see the version that is available to the public in the Google Play Store.
Managing User Feedback
You worked hard to design and build an app based on your understanding of your users’ needs. Now that your app has shipped, your commitment to providing them with responsive customer service shouldn’t end. In fact, depending on the size of your user base, you may need to accelerate your efforts to incorporate user feedback. App Store and Google Play Store user reviews are a great way to stay in touch with your customers’ ongoing desires. This article provides tips on managing user feedback with Apple and Google’s frameworks for requesting ratings and reviews in your app. Both the App Store and Google Play Store provide tools for your customer service team to read and respond to user feedback. Responding to reviews is no different than interacting with users through mediums such as email and discussion forums, so take care to grant access only to team members who know your company’s voice and standards for interaction. You’ll need to grant your team members appropriate access to the tools that let them manage user feedback. Use App Store Connect to give team members access to App Store reviews by taking the following steps: Navigate to the “Roles” section and select “Customer Support” for team members who will be managing App Store reviews. Click on the “Users and Access” tab. Select “Add” (plus button) to grant team members who are in Customer Support roles access to reviews. Choose either “All Apps” or click on individual apps in the Apps section to extend individualized levels of access to each Customer Support team member. You can use the Google Play console to start managing user feedback in a similar way. Take the following steps to grant review access to team members: Give your customer service team members “Reply to reviews” access in the “User feedback” section on the “Account permissions” tab. Select “Users and permissions” in the left sidebar. Click on the “Invite new users” button to give users with “Reply to reviews” access the ability to manage Google Play Store reviews. Now that you’ve given certain users access to reviews, these team members can respond to customer feedback. As with establishing access to customer reviews, the App Store and Google Play Store require similar steps for submitting developer responses. : From the dashboard, click “My Apps” and navigate to the app in question. Select “Ratings and Reviews” in the left sidebar. You will see the app’s average rating and a list of submitted reviews. You may submit one developer response for each review. Google Play Store: From the console dashboard, select “All Apps” and click on the appropriate app in the list to the right. In the left sidebar, select “Reviews” in the “Quality: Ratings and reviews” section. You will see the app’s average rating and a list of submitted reviews. You have the option to submit a developer response for each review shown. When managing user feedback for both platforms, remember that users want to be heard. We recommend that you respond to all reviews, no matter how positive or negative they may be. The developer response will appear publicly in the App Store along with the original user review, so be careful not to include any personal identifiable or otherwise sensitive information in your response. You can provide a customer service phone number or email address to encourage users to contact you directly to address their unique concern (e.g. trouble with their account). Users may submit a rating without providing a review. You will not know which users have submitted ratings without reviews, so you also won’t be able to reply to them or request more information. However, these ratings impact your app’s overall rating. The App Store gives you the option to reset your ratings each time you submit a new version of your app. If the latest version of your app addresses a significant issue that was leading to negative reviews, then you’ll probably want to reset your rating when the update is submitted. Users of the new version will presumably have a better experience and will submit more favorable ratings. The Google Play Store does not offer the same ability to reset ratings for Android apps. Instead, their rating algorithm gives more weight to current ratings than older ones. As you continue to release new and improved versions of your app, the average rating should naturally increase. Both Apple and Google provide a framework for requesting ratings and reviews in your app. We recommend prompting users to do so after they experience a “win” in your app. For a game, this request may connect to a literal win. For a mortgage app, this prompt may follow a successful payment or new knowledge of a great refinance opportunity that will result in extensive savings. Don’t prompt the user to submit a rating when the app launches. At that point, they don’t know enough about your app and are likely to punish you in their ratings for asking too soon. In short, be thoughtful about the timing of your rating request.
Android and iOS App Reviews
Both Android and iOS app reviews are fairly straightforward. Rather than recount the steps involved, this article aims to reduce uncertainty by providing a comparative overview of the two processes. If you have any questions regarding the likelihood that your iOS app will be approved, please consult the official App Store Review Guidelines from Apple: https://developer.apple.com/app-store/review/guidelines/ Google provides a similar resource for the Google Play Store here: https://play.google.com/about/developer-content-policy/ In the early days of the App Store, developers shared horror stories about waiting for weeks for Apple to review their apps. Thankfully, those days appear to be well behind us now. You should expect that the very first review of your app will take longer than subsequent updates. In our experience, the first version of an app in the App Store is reviewed in 2-3 days. Subsequent reviews happen in 0-2 days. Apps in the App Store have always been reviewed by humans. Android apps, on the other hand, used to be reviewed by computers. This difference once made Android reviews much faster than Google’s process. In recent years, Google changed its approach and established an internal review team. In our experience, the first review of a Google Play app takes roughly one week to complete, give or take a few days. Subsequent reviews are much quicker and more in line with the App Store at 0-3 days. Both Apple and Google keep 30% of your app sale, in-app purchase, and subscription profits. Many clients who are new to the stores and this business model look for ways to reduce or eliminate the 30% share by collecting payment outside of apps. You can adopt this approach as long as you don’t use your app to direct users to external payment processes. For example, Amazon’s Kindle app doesn’t allow users to purchase digital books in the app. Instead, users have to complete their transaction on the Amazon website and then download purchased content into the Kindle app. This model aligns with app store financial requirements because the Kindle app does not provide users with guidance on how to make purchases on the Amazon site. Still have questions about how to navigate Android and iOS app reviews and bring an exceptional product to life? Contact us today to learn more about how our Consulting services can help you efficiently execute your next project.
Google Play Store Listing
App Store Listing
Your App Store listing provides users with key information about your iOS digital product. You will need to provide Apple with details about your app so that your listing can be created and your product can become publicly available in the App Store. Listings must include your product’s name, a brief description, screenshots, and more. We’ve provided a comprehensive overview of required information so that you can efficiently navigate the process for creating and updating your App Store listing. We’ve separated listing specifications into two categories—app information and version information. App information is generally consistent across updates and rarely changes. Version information, on the other hand, can and likely will change each time you release a new version of your product. : Your app’s name appears at the top of your App Store listing and is limited to 30 characters. Your app name can be longer than the fairly limited text beneath your app’s icon on a user’s home screen. Subtitle: The subtitle appears beneath your app’s name in the listing in a smaller font. Some clients use the subtitle space to insert a tagline. Subtitles must also be 30 characters or less. Content Rights: Apple requires applicants to demonstrate their legal right to leverage third-party commercial content (such as art and music). Therefore, teams should be prepared to provide this documentation even though it is not included in App Store listings. Primary Language: Your product’s primary language–or the main language that is used for text, audio, and video content in your app–must be specified. Primary and Secondary Category: You will need to choose primary and secondary categories for your app. Your selections will come from the following options: Books, Business, Developer Tools, Education, Entertainment, Finance, Food & Drink, Games, Graphics & Design, Health & Fitness, Lifestyle, Magazines & Newspapers, Medical, Music, Navigation, News, Photo & Video, Productivity, Reference, Shopping, Social Networking, Sports, Stickers, Travel, Utilities, and Weather. Note: If your app is specifically for kids ages 11 and under, be sure to select the “Made for Kids” checkbox to indicate a special categorical case. Age Rating: The age rating is the minimum age for which your app is deemed appropriate. You won’t provide an age rating directly. Instead, you will answer a series of questions about topics that are not suitable for all ages, such as violence and profanity. Apple will then assign an appropriate age rating based on your responses. License Agreement: You may provide your own license agreement or adopt Apple’s policy by default. Pricing and Availability: Your pricing and availability selections are part of your App Store listing. You can establish tiered pricing (e.g. Free, $0.99, $1.99, etc.) and determine which countries should make your app available. When you set pricing, you also specify the effective date for your pricing to change. App Privacy: We cover Apple’s App Privacy questionnaire in depth here. In-App Purchases: If your product includes in-app purchases such as content or features, you’ll configure them in App Store Connect. You may need your development team’s input to complete this task because they may have to implement some app code and/or configuration changes. iPhone Screenshots You need to provide between 1 and 10 screenshots for your app. Your screenshots must also meet very specific pixel dimensions to satisfy Apple’s requirements. For iPhone apps, Apple requires teams to provide images for 6.5” screens (iPhone 12 Pro Max, iPhone 11 Pro Max, iPhone 11, iPhone XS Max, iPhone XR) and 5.5” screens (iPhone 8 Plus, iPhone 7 Plus, iPhone 6s Plus). The required pixel dimensions for 6.5” and 5.5” screens are as follows: 6.5” screenshots: 1284 x 2778 pixels (portrait) or 2778 x 1284 pixels (landscape) 5.5” screenshots: 1242 x 2208 pixels (portrait) or 2208 x 1242 pixels (landscape) Apple gives teams the option to provide specific images for 5.8” screens (iPhone 12 Pro, iPhone 12, iPhone 12 mini, iPhone 11 Pro, iPhone XS, iPhone X) as well as 4.7” screens (2nd generation iPhone SE, iPhone 8, iPhone 7, iPhone 6s, iPhone 6). If your team does not submit images for smaller screens, then Apples will scale your 6.5” and 5.5” images. Some teams have access to specific devices that produce screenshots with the required size dimensions. These applicants can then simply capture images and upload them to App Store Connect. If your team does not have this capability, it may be easiest to take representative screenshots on whatever device you have and then lean on our team to capture the shots using an iOS Simulator, which allows us to meet the specifications of any iPhone model. Most App Store listing screenshots show the edge-to-edge UI of your app. However, some clients prefer to reduce the size of the image, insert it into a phone frame, and possibly add some promotional or instructional text around the images. If you choose to further customize your screenshots, keep the following additional requirements in mind: The “frame” of the mobile device pictured must be an iPhone. Apple requires that users only see their own device’s frame in screenshots they view in the App Store as well. This means that if a user visits the App Store using their iPhone 8, they can’t, for example, be presented with screenshots showing the frame of an iPhone X. You’ll need to produce a set of images for all of the screen sizes (6.5”, 5.8”, 5.5”, and 4.7”) with the appropriate device frame for each one. Since you can’t rely on Apple to resize images, you’ll need to know the dimensions of certain iPhone screens. For reference, here are the image dimensions for 5.8” and 4.7” devices: 5.8” screenshots: 1170 x 2532 pixels (portrait) or 2532 x 1170 pixels (landscape) 4.7” screenshots: 750 x 1334 pixels (portrait) or 1334 x 750 pixels (landscape) To provide you with a real-world example, the following images show how TikTok handles various presentations across different device models: iPad Screenshots If your app runs on iPad, the screenshot requirements are similar. You must provide screenshots for a 12.9” iPad screen (3rd and 4th generation iPad Pro). Images for devices with the following screen sizes are optional: 11” (iPad Pro, 4th generation iPad Air), 10.5” (7th and 8th generation iPad, iPad Pro, iPad Air), and 9.7” (iPad, iPad mini). We recommend that you provide additional screenshots if you either 1) don’t want Apple to auto-scale the 12.9” images, or 2) want to provide screenshots inserted into a device frame. We’ve listed all of the dimensions below. 12.9” screenshots (required): 2048 x 2732 pixels (portrait) or 2732 x 2048 pixels (landscape) 11” screenshots: 1668 x 2388 pixels (portrait) or 2388 x 1668 pixels (landscape) 10.5” screenshots: 1668 x 2224 pixels (portrait) or 2224 x 1668 pixels (landscape) 9.7” screenshots: 1536 x 2008 pixels (portrait (without status bar) / 1536 x 2048 pixels (portrait with status bar) or 2048 x 1496 pixels (landscape without status bar) / 2048 x 1536 pixels (landscape with status bar) If there are any mobile devices pictured in your screenshots (for instance, a stock photo of a model holding a phone on your login page), then the mobile products shown must be Apple devices. If your iOS app includes an image of an Android phone, your app will likely be rejected in the review process. App Previews are short videos that show your app in action. They must be between 15 and 30 seconds in length and no more than 500 MB in size. Apple automatically makes the 5-second mark your poster frame. The supported file formats are .mov, .m4v, and .mp4. If your app preview includes screenshots, you must meet the requirements for both 6.5” and 5.5” iPhone screens. You have the option to submit other sizes. If you choose not to submit other sizes, Apple automatically derives scaled versions of the 6.5” or 5.5” videos for other devices . Required Dimension Supported Formats Promotional Text: Use promotional text for special occasions or to draw attention to something unique. This optional content appears above the description in the App Store. Promotional content is one of the few things that you can update without a new review. Apple limits promotional text to 170 characters or less. Description: Your app description of the features and benefits of your app can be up to 4,000 characters. Keywords: Keywords don’t appear in the listing but are used to improve search results in the App Store. You’ll provide a comma-separated list of words. Keep in mind that commas between words count toward your 100 character limit. Support URL: Provide a support URL link to the page on your website where users can find customer help and resources for your app. Marketing URL: Submit an optional marketing URL link to a page on your website where users can find product information about your app. App Review Contact Information: Provide contact information including the name, phone number, and email address of the person Apple can reach if they have questions during the review process. In our 13 years of developing App Store listings, we’ve never been contacted using these methods. All of our review feedback has come through a dedicated channel within App Store Connect for review-related communication. App Review Notes: If you need to give the reviewer special instructions for using features of the app, include them in your review notes. Only include details that are less obvious to someone picking up the app for the first time. Authentication Details: Create authentication details (typically a username and password) for the reviewer if login is required for your app. If your app uses something other than a username and password, provide these details in the app review notes. Be sure that you can authenticate these credentials in your production environment before submitting a new build for review. If an Apple team member can’t log in, then your review will stop until the issue is resolved. Attachment: You can submit an attachment in a wide variety of formats to support your submission. While teams may submit attachments as images, PDFs, and other formats, our clients most frequently submit videos for their reviews. Videos are necessary for at least two of the following common circumstances: You can’t provide Apple with a live test account in your production environment. This is the case for some of our financial clients. Your app integrates with hardware that the reviewer can’t access. If this describes your situation, then it is important to record a video that shows your app running on a phone and communicating with its associated hardware at the same time. The reviewer needs to see, for instance, that when you tap a button in your app’s UI, the light on the hardware turns green. In both cases, it is crucial to demonstrate the core functionality of your app. However, teams certainly don’t need to demonstrate every possible use case. We recommend that you keep your video to 2 minutes or less. Remember that the reviewer can pause and rewind as needed, so you can fly through your demo. You don’t need to narrate it either, unless you think your app has a specific feature that requires an explanation. This situation is rare.
Web Setup (domain, SSL certificate, and more)
Our team is here to help you create a web setup for your digital product. In order to facilitate this process, InspiringApps will need access to your domain name, SSL certificate, and transactional email address. Follow the guide below to begin establishing an online presence that will contribute to your app’s rise to the top of the digital market. Your domain name, which is essentially the internet equivalent of a physical address, adds credibility to your product and helps define your online brand. No matter where you’re at in the web setup process, our team is here to help you take ownership of a domain name that’s perfect for your app. What we’ll need from you: You’ll need to establish an admin account for InspiringApps at your domain registrar (the organization that provides your domain name registration to the general public). A few examples of domain registrars are GoDaddy, Namecheap, and Name.com. The exact process for creating a new admin account varies by domain registrar. InspringApps can help you create & share credentials in a secure way. How to optimize your current domain name: InspringApps can handle everything that’s needed to update your existing domain name to point to your new web app. Not happy with your current domain registrar? No problem. Once InspiringApps has an account with your current domain registrar, we can also help you transfer your domain to another organization. What we’ll need from you: Just a quick discussion about what domain name to create! InspiringApps will register a domain at a reputable domain registrar that also effectively integrates with your project’s tech stack. SSL certificates are a crucial piece of modern apps and web setup. For a specific domain (for example, yourapp.com), SSL certificates ensure that the traffic between your users and the server is secure. What we’ll need from you: We highly recommend having InspiringApps create a new certificate for your web app whenever possible. If certain circumstances require your team to use an existing SSL certificate, InspiringApps will work with your engineering team to acquire the: SSL Certificate File SSL Certificate Key File Renewal process Renewal schedule What we’ll need from you: Nothing! InspiringApps can handle the entire process for establishing a new certificate for your app, including navigating the renewal process. A transactional email address is essential to your web setup. It is the email from which your users will receive emails related to invitations, password resets, and other automated notifications. In addition to establishing a transactional email address, we recommend using an email delivery service such as Postmark, SendInBlue, SendGrid, or MailChimp. These services allow easy configuration of highly-deliverable emails (that won’t be diverted to spam folders) and also provide additional tracking metrics. What we’ll need from you: If you’re not using an additional delivery system (e.g. Postmark, MailChimp, or a similar system), then we’ll need a set of login credentials for your “from” email account. Otherwise, if you are using an additional delivery service, then we’ll need you to provide the SMTP connection information below. Host (e.g. smtp.postmark.com) Port Is-Secure Flag (true or false) Username Password From Email Address Alias Name (e.g. The InspiringApps Team) Note: If you can’t find this information, no problem! InspringApps has worked with many SMTP providers and can help you track down everything that’s needed. What we’ll need from you: Just a quick discussion about choosing a transactional email address that’s right for your product! Our team is here to provide guidance on how to set up a secure, professional-looking “from” address.