Ablehnung wegen Background Mode in der App

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Ablehnung wegen Background Mode in der App

    Hallo Zusammen,

    wurde jemand schon mal in App Store wegen des Background Modus in der P-Liste abgelehnt ? Meine App benutzt dem Background Modus um Regionen zu überwachen, wenn ich diese Funktion rausnehme ist der Komfort der App leider weg. Hat das jemand schon mal gehabt, wenn ja wie ist der Spaß ausgegangen?

    Gruß Marvin
  • Frage ist ja auch was du da im background Modus alles machst. Ein wichtiger Punkt ist ja, dass man im background zwar Regionen überwachen darf (das macht ja heute jede zweite App) man aber nicht wer weiß was damit arbeiteten. Sprich die cpu und Memory last muss möglichst gering bleiben.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Die Begründung von Apple

    Guideline 2.5.4 - Performance - Software Requirements


    We noticed that your app declares support for location in the UIBackgroundModes key in your Info.plist file but does not have any features that require persistent location. Specifically, your app uses location background mode for the sole purpose of tracking employees, which is not appropriate on the App Store.

    Next Steps

    To resolve this issue, please revise your app to include additional features for your users that require the persistent use of real-time location updates while the app is in the background.

    If tracking your employees' locations is your only intended use of background location, it would be more appropriate to distribute and sell your app as a custom B2B app, directly to the specific company, through the Volume Purchase Program. Additional information about the Volume Purchase Program and the Custom B2B Store is also available in App Store Connect Developer Help.

    Die App ist eine Zeiterfassung, somit werden bei einer selbst eingegebener Region Zeiten lokal auf dem iPhone in CoreData gespeichert.
  • Es werden hier nur Regionen überwacht, die Genauigkeit kann man zwar einstellen, aber ich glaube bei den Funktionen DidEnterRegion und die ExitRegion würde das keine Rolle spielen. Der User erstellt einen Ort und der wird dann über die locationManager.startMonitoring(for: "Hier der Ort") Funktion über wacht mehr ist da nicht.

    Die info.plist

    XML-Quellcode

    1. <?xml version="1.0" encoding="UTF-8"?>
    2. <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    3. <plist version="1.0">
    4. <dict>
    5. <key>CFBundleDevelopmentRegion</key>
    6. <string>de_DE</string>
    7. <key>CFBundleDisplayName</key>
    8. <string>Stechuhr Pro</string>
    9. <key>CFBundleDocumentTypes</key>
    10. <array>
    11. <dict>
    12. <key>CFBundleTypeName</key>
    13. <string>CSV Document</string>
    14. <key>CFBundleTypeRole</key>
    15. <string>Viewer</string>
    16. <key>LSHandlerRank</key>
    17. <string>Owner</string>
    18. <key>LSItemContentTypes</key>
    19. <array>
    20. <string>Damian-s.${PRODUCT_NAME:rfc1034identifier}</string>
    21. </array>
    22. </dict>
    23. </array>
    24. <key>CFBundleExecutable</key>
    25. <string>$(EXECUTABLE_NAME)</string>
    26. <key>CFBundleIdentifier</key>
    27. <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string>
    28. <key>CFBundleInfoDictionaryVersion</key>
    29. <string>6.0</string>
    30. <key>CFBundleName</key>
    31. <string>$(PRODUCT_NAME)</string>
    32. <key>CFBundlePackageType</key>
    33. <string>APPL</string>
    34. <key>CFBundleShortVersionString</key>
    35. <string>1.0</string>
    36. <key>CFBundleVersion</key>
    37. <string>13</string>
    38. <key>ITSAppUsesNonExemptEncryption</key>
    39. <false/>
    40. <key>LSRequiresIPhoneOS</key>
    41. <true/>
    42. <key>LSSupportsOpeningDocumentsInPlace</key>
    43. <true/>
    44. <key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
    45. <string>You'll need to share the location service for the Stechuhr Pro to record your working hours with GPS. The location data is stored only on your device, we have no access to your data.</string>
    46. <key>NSLocationAlwaysUsageDescription</key>
    47. <string>You'll need to share the location service for the Stechuhr Pro to record your working hours with GPS. The location data is stored only on your device, we have no access to your data.</string>
    48. <key>NSLocationWhenInUseUsageDescription</key>
    49. <string>You'll need to share the location service for the Stechuhr Pro to record your working hours with GPS. The location data is stored only on your device, we have no access to your data.</string>
    50. <key>UIBackgroundModes</key>
    51. <array>
    52. <string>location</string>
    53. <string>remote-notification</string>
    54. </array>
    55. <key>UILaunchStoryboardName</key>
    56. <string>LaunchScreen</string>
    57. <key>UIMainStoryboardFile</key>
    58. <string>Main</string>
    59. <key>UIRequiredDeviceCapabilities</key>
    60. <array>
    61. <string>location-services</string>
    62. <string>gps</string>
    63. </array>
    64. <key>UISupportedInterfaceOrientations</key>
    65. <array>
    66. <string>UIInterfaceOrientationPortrait</string>
    67. </array>
    68. <key>UISupportedInterfaceOrientations~ipad</key>
    69. <array>
    70. <string>UIInterfaceOrientationPortrait</string>
    71. <string>UIInterfaceOrientationPortraitUpsideDown</string>
    72. <string>UIInterfaceOrientationLandscapeLeft</string>
    73. <string>UIInterfaceOrientationLandscapeRight</string>
    74. </array>
    75. <key>UTExportedTypeDeclarations</key>
    76. <array>
    77. <dict>
    78. <key>UTTypeConformsTo</key>
    79. <array>
    80. <string>public.data</string>
    81. </array>
    82. <key>UTTypeDescription</key>
    83. <string>CSV Document</string>
    84. <key>UTTypeIdentifier</key>
    85. <string>Damian-s.${PRODUCT_NAME:rfc1034identifier}</string>
    86. <key>UTTypeTagSpecification</key>
    87. <dict>
    88. <key>public.filename-extension</key>
    89. <string>csv</string>
    90. <key>public.mime-type</key>
    91. <string>application/inventorytodo</string>
    92. </dict>
    93. </dict>
    94. </array>
    95. </dict>
    96. </plist>
    Alles anzeigen
  • Hallo Marvin,

    wenn es sich bei der App um eine App handelt bei der man für sich selbst (persönlich) ein Tracking machen kann, dann würde ich das an deiner Stelle nochmal mit Apple besprechen.
    Du musst Apple dann klarmachen, dass diese Funktion eine Funktion ist die für die Benutzer selbst sinnvoll, sprich ein Feature ist (und nicht nur zum Daten abgreifen).
    In diesem Fall macht es durchaus Sinn das zuzulassen, da es eine durchaus sinnvolle Funktion für jemanden sein kann, der seine Zeit an bestimmten Orten tracken möchte.

    Wenn es sich um eine generelle App für Firmen zur "Mitarbeiterüberwachung" handelt dann wird das Argument des Reviewers eventuell greifen.

    Generell gilt: Ein Verweis auf andere Apps, die das eventuell auch machen, hilft meines Wissens in der Regel nicht weiter.
  • Hallo Flexxx,

    es handelt sich hier um die erste beschriebene Variante, der Benutzer kann sich selbst Ort anlegen und dann wird die Zeit gespeichert, kein anderer hat Zugriff auf die Daten. Ich hatte das mit Apple in der Review schon schriftlich beschrieben, aber das Review Team nimmt die Argumentation nicht an oder verstehen das nicht. Ich glaube das hat nix mit Datenschutz zu tun, vielmehr denke ich das die meinen das der Ständige Hintergrunddienst die Funktion meiner App nicht rechtfertigt. Wenn ich den Haken bei Background Location rausnehme wird die App wahrscheinlich durchgehen, allerdings geht dann die GPS Funktion nicht richtig. Ein Verweis auf andere App werde ich auch nicht machen, war hier nur die Frage ob einer schon Mals das Problem hatte.
  • Marvin75 schrieb:

    Hallo Flexxx,

    ...Ich glaube das hat nix mit Datenschutz zu tun, vielmehr denke ich das die meinen das der Ständige Hintergrunddienst die Funktion meiner App nicht rechtfertigt...
    Hallo Marvin,

    genau das meinte ich, "Daten sammeln" wäre hier kein hinreichender Grund. Wenn du das schon mit denen besprochen hast und die nicht darauf eingehen, dann wäre vermutlich das einzige um das noch reinzukriegen, dass du noch eine Zusatzfunktion einbaust die Sinn macht (welche die Hintergrundfunktion nutzt). In der Hoffnung das dann die Nutzung des Features aus Apples Sicht gerechtfertigt ist. Vielleicht fällt dir da ja was sinnvolles ein...
  • Hallo Zusammen,

    ich wollte mal die Rückmeldung geben, die App ist jetzt im Appstore, sie hat dann auch die Guideline bestanden.

    Folgendes habe ich gemacht

    1. Den Hacken beim Background Modus Location entfernt
    2. Für das Objekt Locationsmanager habe ich den Befehl locationManager.allowsBackgroundLocationUpdates = false eingefügt


    Danach hat die Funktion "Monitored Regions" wieder funktioniert und Apple war Happy.

    Für diese Funktion wird kein BackgroundModus benötigt. In der PList.info habe ich alles so gelassen wie es war.

    Danke für Eure Unterstützung.

    Gruß Marvin
  • Sorry, aber die Kritik kann ich nicht nachvollziehen: Klar, über das UI kann man streiten, aber wenn die App hilfreich ist, geht der Preis eines Cappuccinos m. E. vollkommen in Ordnung.

    Ich finde schon schlimm genug, dass „normale Benutzer“ alles > 99 Ct. als Wucher empfinden und kein Relation zwischen Nutzen, Entwicklungsaufwand und Kosten sehen ... gerade bei Nischenlösungen. Von einem Entwickler hätte ich diese Ansicht nicht erwartet.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Keine Ahnung wo du was von Wucher gelesen hast oder das da reininterpretierst

    Wenn ich ne App kaufe, egal zu welchem Preis dann benutze ich sie häufiger
    Und neben der Funktionalität gehört nun mal auch UI und UX dazu.

    Und das UI ist, für mich, nun mal alles andere als ansehnlich.
    Und widerspricht auch komplett dem was Apple mit seinen aktuellen Betriebssystemen und Guidelines vorgibt.

    Zu mal die ja selber sagst über das UI kann man streiten.
    Ich weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. :saint:
  • Ich kann die Kritik zwar nicht ganz nachvollziehen, aber über Geschmack lässt sich ja bekanntlich streiten, aber es wird ja auch niemand gezwungen meine App zu kaufen. Die App hat vielleicht für manche einen sehr hohen Nutzen. Das UI kann man ja auch in den nächsten Versionen anpassen, die Funktion war für mich erstmal an 1. Stelle.
    Ich weiß nicht ob Du eine Vorstellung hast wieviel Zeit das Entwickeln einer App in Anspruch nimmt und was Du schlussendlich von Apple überwiesen bekommst, wenn Du eine 2,29€ App in den Store stellst. Zu den Guidelines kann ich Dir sagen, wenn die App im Store ist, ist sie durch die Guideline durchgekommen und glaube mir, ich habe da mittlerweile schon Erfahrungen gesammelt.

    Das Pro kam aus der ersten Idee raus, ich wollte eine "Lite" Version und eine Pro Version mit InApp Käufen machen, habe mich dann doch umentschieden, da ich diese Abo Scheiße nicht mag. Ich finde den Preis von 2,29€ für die Zeit, die mich die App gekosten hatte, neben meiner "normalen" Arbeit, vollkommen OK.

    Was mich mal interessieren würde, entwickelst Du App und stellst diese in den Store? Wenn ja würde ich mir gerne mal Deine Apps ansehen, wie die aussehen und was die App so macht. Vielleicht kann man da ja noch was lernen wie schön UI geht :)

    Im Übrigen lässt sich das Hintergrundbild auch auswählen. Man kann Farben und Hintergrundbild auswählen.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Marvin75 ()

  • Ich sehe UI und Preis einer App als zwei nahezu komplett getrennte Aspekte:
    • Auch eine kostenlose App sollte über ein geeignetes UI verfügen. Dabei heisst „geeignet“ für mich, dass es die Funktion der App bzw. die Arbeitsabläufe des Benutzers unterstützt und ansprechend ist ... letzteres ist nur teilweise subjektiv, ersteres gar nicht („Form follows function“).
    • Der Preis einer App spiegelt vieles wider: Neben Konkurrenzsituation, Aufwand, Nutzen, Zielgruppe sowie allgemeiner Preispolitik, natürlich auch die Umsetzung. Hier ist UI zwar ein Faktor, aber eben nur einer.

    Marvin75 schrieb:

    Das Pro kam aus der ersten Idee raus, ich wollte eine "Lite" Version und eine Pro Version mit InApp Käufen machen, habe mich dann doch umentschieden, da ich diese Abo Scheiße nicht mag.
    Nur eine Anregung: In-App-Purchase ist nicht gleich Abo. Gerade bei etwas komplexeren Apps finde ich eine eingeschränkte, kostenlose Trail-Version mit einem IAP zur Freischaltung sinnvoll: Potentielle Kunden können ohne Risiko ausprobieren, während der Entwickler etwas hochpreisiger agieren kann.

    BTDT ... hier ein Link zu einer meiner Apps.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Da das Kundenprojekte sind, werde ich die nicht veröffentlichen.

    Zum anderen ist eine solche Diskussion auch mehr aus sinnfrei. Bei allem was Dir jetzt gezeigt würde würdest du solange suchen bist du irgendwas findest.

    Und @MyMattes
    „Das Auge ist nun mal mit“
    Ich sehe UI und Preis nicht getrennt.
    Beispiel aus einer anderen „Welt“:
    Jedes Auto bringt dich von A nach B
    Geld für einen Fiat Multipla würde ich trotzdem nicht ausgeben.
    Gratis würde ich das Ding aber auch fahren bis er auseinander fällt.

    Und genau so ist es auch bei Software, wenn ich das jeden Tag benutze weil es mir ne wichtige Aufgabe abnimmt. Dann will ich auch das es dem Preis angemessen ausschaut.

    Und das ist hier, MEINER MEINUNG nach, nicht gegeben.
    Da ich hier niemanden beleidigt habe. Sollte man das halt akzeptieren.
    Diskutieren scheint hier ja nicht mehr erwünscht zu sein.
    Ich weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. :saint:

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von nussratte ()