Seeking Guidance: App Store Rejection Under Guideline 4.3(a) - Detailed Differentiation Already Provided

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:

  1. How have developers effectively demonstrated feature differentiation?
  2. What technical documentation best demonstrates unique implementations?
  3. What strategies work for showing market demand for new features?
  4. 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.

Answered by App Review in 817994022

Thank you for your post and appeal. We're investigating and will contact you in App Store Connect to provide further assistance. If you continue to experience issues during review, please contact us.

Accepted Answer

Thank you for your post and appeal. We're investigating and will contact you in App Store Connect to provide further assistance. If you continue to experience issues during review, please contact us.

Thank you for your follow up.

We will be on standby for any further feedback.

We were able to address and move past all previous issues in App review swiftly except this one as outlined above and in more details within the rejected App Review itself.

We look forward to your feedback/investigation, please let us know if we can provide any further materials towards that at any time.

Kind Regards

Muhammed Jobe

@Leo Following our previous resolution on the "design spam" issue - where we demonstrated our unique implementation, custom code, and community features - we're now facing a new submission (ID: fa69f469-2043-4069-a8be-249916c564ed) that's being blocked by similar template responses.

The new rejection claims:

  1. That we don't have ATT implementation (we do, with screenshots)
  2. That we need to change "Enable Location" to "Continue" (less transparent for users)
  3. That the app should work without location (impossible for an Islamic prayer app to get prayer times, as told we did make Quran available without login and prayer times but we cannot calculate prayer times without location)

We've provided detailed evidence for each:

  • Screenshots showing working ATT implementation
  • Two-step location permission process with proper iOS system prompts
  • Clear explanation why location is required for Islamic prayers:
    • Prayer times must be calculated based on sun position
    • Qibla direction needs user location relative to Mecca
    • All Islamic prayer apps require this for religious accuracy

But just like our previous "design spam" situation, we're getting template responses that completely ignore:

  1. Our provided screenshots
  2. Working implementations they claim don't exist
  3. Religious requirements that make some suggestions impossible
  4. Previous verification of our unique features

After your help resolving the earlier "design spam" issue, this feels like déjà vu - providing clear evidence but getting template responses that don't acknowledge it.

Any guidance on breaking through this cycle would be incredibly appreciated, especially given how we resolved the previous situation.

If we need to make another appeal to the App Review Board for this please let us know and I'll get to that right away.

My apologies, shouldn't have addressed Leo on this he provided support on the actual App Reviews.

Ive gone ahead and created an app with App Review Board.

I hope this can get some eyes otherwise I'll try and make another post. Really hoping we can resolve this before December 20 as we were informed things will get busier post this.

Seeking Guidance: App Store Rejection Under Guideline 4.3(a) - Detailed Differentiation Already Provided
 
 
Q