Seeking developer insights regarding a 4.3(a) review response citing "similar binary, metadata, and/or concept." Our app implements distinct community-focused features that fundamentally differentiate it from existing applications in this category. Feature Implementation: Our app introduces new technological approaches to faith-based applications: Community System: Custom-built group participation with progress visualization Engagement Features: Peer support system with achievement tracking Progress Metrics: Proprietary points system for progress tracking Group Progress Features: Shared accomplishment tracking Achievement Architecture: Progress continuity tracking Performance metrics accumulation Custom recognition system for personal and group milestones Synchronized goal-setting framework Market Analysis: Our research indicates: No existing apps with group-based progress features No solutions combining community features with scheduling No applications with similar group achievement systems No platforms featuring synchronized progress tracking Substantial user base requesting these features Technical Questions: How have developers effectively demonstrated feature differentiation? What technical documentation best demonstrates unique implementations? What strategies work for showing market demand for new features? Best practices for documenting novel community features? Implementation Context: While core scheduling features necessarily overlap with existing solutions, our platform's focus on community engagement and achievement tracking represents a novel approach, validated through user research and community feedback. Seeking insights from developers who have successfully implemented unique social features in established categories.

Hi all, Very new to this. Just getting into swift data, and am frustrated with the canvas not working with modelContainers in SwiftData. My understanding is that they work if inMemory = true, but not in the default case where data is persistent after an app is quit. Can anyone tell me if it is possible to conditionally create the modelContainer type based on a flag... If Bool:Canvas then inMemory = True, Else False... Then using this flag for all data models so my list views populate on the canvas, without having to run the simulator each time... I would assume you could also pre-populate the inMemory option if it is empty also... Or is there a simple and obvious solution that I am oblivious to. If it is possible, is it worth the time, hassle, and any possible issues?

I recently got feedback for my app under Guideline 4.2 - Design - Minimum Functionality, and I’m a bit confused. Apple mentioned that the app isn’t “app-like” enough and doesn’t provide sufficient entertainment value or utility. However, I genuinely think my app is unique compared to others on the market. Most similar apps only offer basic features like scorekeeping and saving the game. My app goes beyond that by tracking detailed statistics based on the types of scores achieved during the game. At the end, there’s even a Player Ratings section, which enhances competition and makes the experience more fun for players. Additionally, in today’s gaming scene, many groups play the traditional 101 game with a reward and penalty system. My app uniquely incorporates a reward system, something no other app in the market currently offers. I believe my app has the potential to stand out and meet the needs of a wide audience. Has anyone faced similar feedback? Or does anyone have suggestions on how I could better address this issue? Thanks in advance! 😊

It is outrageous that Apple continue to fail to implement the Fullscreen API web standard for web apps on iPhone only, which is so important to accessibility and web app functionality. The only possible reason for this block is commercial: to promote iOS apps instead of browser based web apps. To quote a client from a major agency just now - a typical enquiry : We value accessibility greatly, and we noticed that the embedded player is missing a full screen button on iPhone. Everything else works perfectly fine, including a full screen button that appears on the mobile webpage on android devices. Is there any way we can include a button to enable full screen view for our viewers in your player that are going to watch it on iOS devices? To which, as usual, we have to reply: Apple unfortunately block fullscreen mode from being used with all web applications on iPhone. Apple will allow this to be displayed fullscreen on MacBooks and iPads, but currently not on on iPhone - so we have to hide the fullscreen button there. So fullscreen works on all devices and browsers apart from on iPhone. As you've seen with Android, all other devices and browsers follow the universal 'Fullscreen API' web standard to allow full screen. You're probably familiar with seeing the fullscreen button on normal linear videos on iPhone. These use Apple's native video player, which doesn't let buttons and scripts be used on top of it - just a single video, not an interactive web application. Our player looks like a video player but it is actually a web app combining multiple different video clips connected together by code and styling. They block it on iPhones for reasons known only to them, but the assumption is that it is to incentivise people to make iOS apps instead of web apps. The web development community is hopeful that Apple will change this unfortunate restriction soon, but we have been waiting a long time in vain. We have to send this to a lot of people. It's a very bad look for Apple. In less than a month it will be 2025. We have been waiting years for this. The web standard documentation showing universal support on other devices and browsers is here: https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API This is not acceptable. It is time for Apple to stop blocking this important accessibility web standard for commercial reasons - only on iPhone. To whoever is in charge of these decisions in the Safari/Webkit team: Please just enable Fullscreen API for web apps on iPhone as soon as possible.

I need this app solution

Emoji keyboard are way too big after updating to IOS 18.1 so anoying to use emojis now. I really don't like using emojis anymore. I really hope they are going to fix this quickly. I use my phone for work and pleasure. I don't needing my heart to be bigger or different colors to every reaction. Please bring back the smaller emoji keyboard or add a setting to switch it back. This is really annoying.

I like this font. but in license only allowed for use in Mockup UI. Feel free to use in commercial? https://mobbin.com/apps/bloom-ios-e1251835-34e6-426e-9f94-f9595f2567fa/1c919e9a-d144-4aa0-b788-f9752111e281/screens

I'm trying to make a Swift Chart where 24 AreaMarks an hour apart on X axis over a day display a vertical gradient. The gradient is vertical and is essentially [Color.opacity(0.1),Colour,Color.opacity(0.1] The idea here is where the upper and lower points of each AreaMark are the same or close to each other in the Y axis, the chart essentially displays a line, where they are far apart you get a nice fading vertical gradient. However, it seems that the .alignsMarkStylesWithPlotArea modifier is always set for AreaMarks even if manually applying it false. Investigating further, I've learnt that with AreaMarks in a series, Swift Charts seems to only listen to the first foreground style set in. I've created some sample code to demonstrate this. struct DemoChartView: View { var body: some View { Chart { AreaMark(x: .value("Time", Date().addingTimeInterval(0)), yStart: .value("1", 40), yEnd: .value("2", 60)) .foregroundStyle(LinearGradient(colors: [.pink, .teal], startPoint: .top, endPoint: .bottom)) .alignsMarkStylesWithPlotArea(false) AreaMark(x: .value("Time", Date().addingTimeInterval(3600)), yStart: .value("1", 44), yEnd: .value("2", 58)) .foregroundStyle(LinearGradient(colors: [.orange, .yellow], startPoint: .top, endPoint: .bottom)) .alignsMarkStylesWithPlotArea(false) AreaMark(x: .value("Time", Date().addingTimeInterval(03600*2)), yStart: .value("1", 50), yEnd: .value("2", 90)) .foregroundStyle(LinearGradient(colors: [.green, .blue], startPoint: .top, endPoint: .bottom)) .alignsMarkStylesWithPlotArea(false) } } } Which produces this: So here, all the different .foregroundStyle LinearGradients are being ignored AND the .alignsMarkStylesWithPlotArea(false) is also ignored - the amount of pink on the first mark is different to the second and third 🤷‍♂️ Has anyone encountered this. Are AreaMarks the correct choice or are they just not setup to create this type of data display. Thanks

Hello, I noticed a small mistake in the Human Interface Guidelines (HIG). On the page HIG > Components > System Experiences > Widget > watchOS Widget Dimensions, scroll down to the bottom. In the "watchOS widget dimensions" section, the sizes in the table are in pixels (px), not points (pt) actually. However, the table header indicates the sizes should be in points (pt). Page link: https://developer.apple.com/design/human-interface-guidelines/widgets#watchOS-widget-dimensions For example, the widget size in the Smart Stack on a 49mm watch should be 192x81.5 pt (or 382x163 px), not 382x163 pt. This size can be verified with the information provided here: https://developer.apple.com/documentation/watchos-apps/supporting-multiple-watch-sizes/. https://developer.apple.com/documentation/watchkit/wkinterfacedevice/1620974-screenscale

Hello, Our app rejected by following reason: Guideline 4.3 - Design We noticed your app shares a similar binary, metadata, and/or concept as apps previously submitted by a terminated Apple Developer Program account. Submitting similar or repackaged apps is a form of spam that creates clutter and makes it difficult for users to discover new apps. Next Steps Since we do not accept spam apps on the App Store, we encourage you to review your app concept and submit a unique app with distinct content and functionality. Resources Some factors that contribute to a spam rejection may include: Submitting an app with the same source code or assets as other apps already submitted to the App Store Creating and submitting multiple similar apps using a repackaged app template Purchasing an app template with problematic code from a third party Submitting several similar apps across multiple accounts Learn more about our requirements to prevent spam in App Store Review Guideline 4.3. iOS App 1.0App Version Rejection Reasons: 4.3.0 Design: Spam The application is 100% developed by our team and I am 100% sure of it. How can we do it ? Please help.