iPhone 应用因使用 ICU(Unicode 扩展)而被拒绝

发布于 2024-08-25 07:53:08 字数 632 浏览 4 评论 0原文

我收到了 Apple 发送的以下邮件,考虑了我的申请:


感谢您向 App Store 提交 NOμοθεσία 的更新。在我们审查您的应用程序期间,我们发现它正在使用私有 API,这违反了 iPhone 开发者计划许可协议第 3.3.1 节; “3.3.1 应用程序只能按照 Apple 规定的方式使用记录的 API,不得使用或调用任何私有 API。”虽然您的申请未被拒绝,但最好在下次更新中解决此问题。 您的应用程序中包含以下非公共 API: u_isspace ubrk_close ubrk_当前 ubrk_first ubrk_next ubrk_open 如果您在源代码中定义了与上述 API 名称相同的方法,我们建议更改您的方法名称,以便它们不再与 Apple 的私有 API 冲突,以避免您的应用程序在将来的提交中被标记。 请在下次更新 NOμοθεσία 时解决此问题。 真挚地, iPhone应用程序审查团队


本邮件中提到的功能在ICU库(Unicode国际组件)中使用。 虽然我的应用程序此时没有被拒绝,但我对我的应用程序的未来感到不太安全,因为它严重依赖 Unicode 协议,尤其是此组件。 另一件事是,我不直接调用这些函数,而是由自定义“sqlite”构建(启用 FTS3 扩展)调用它们。

我在这里错过了什么吗? 有什么建议吗?

I received the following mail form Apple, considering my application:


Thank you for submitting your update to Νομοθεσία to the App Store. During our review of your application we found it is using private APIs, which is in violation of the iPhone Developer Program License Agreement section 3.3.1; "3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs." While your application has not been rejected, it would be appropriate to resolve this issue in your next update.
The following non-public APIs are included in your application:
u_isspace
ubrk_close
ubrk_current
ubrk_first
ubrk_next
ubrk_open
If you have defined methods in your source code with the same names as the above mentioned APIs, we suggest altering your method names so that they no longer collide with Apple's private APIs to avoid your application being flagged with future submissions.
Please resolve this issue in your next update to Νομοθεσία.
Sincerely,
iPhone App Review Team


The functions mentioned in this mail are used in the ICU library (International Components for Unicode).
Although my app is not rejected at this point, I don't feel very secure for the future of my app, because it relies heavily on the Unicode protocol and on this components in particular.
Another thing is that I do not call these functions directly, but they are called by a custom 'sqlite' build (with FTS3 extensions enabled).

Am I missing something here?
Any suggestions?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

初见终念 2024-09-01 07:53:08

我建议不要公开发泄这个问题(从长远来看,这可能只会伤害你),而是礼貌地回复你收到的应用程序审核电子邮件地址,解释你正在使用引用 ICU 框架的自定义 SQLite 构建。鉴于这是一个标准的第三方框架,我认为这些不是您正在使用的 Apple 的私有 API。也许他们只是过于热心地在扫描软件中包含符号。

如果您无法说服他们,您可以考虑从带有 FTS3 的 SQLite 切换到 Aaron Hillegass 的 之类的东西BNRPersistence,它刚刚添加了快速全文搜索。

I would recommend not publicly venting about the issue (that might only hurt you in the long run), but responding politely to the application review email address you were given, explaining that you are using a custom SQLite build which references the ICU framework. Given that this is a standard third-party framework, I would argue that these are not Apple's private APIs that you are using. It may be that they were simply overzealous in the inclusion of symbols in their scanning software.

If you are unable to convince them otherwise, you might contemplate switching from SQLite with FTS3 to something like Aaron Hillegass' BNRPersistence, which just added fast full-text searching.

新人笑 2024-09-01 07:53:08

如果他们在链接到系统 ICU 时遇到问题,为什么不简单地将 ICU 源代码导入到您的项目中呢?

If they have trouble with linking to the system ICU, why not simply import the ICU source code into your project?

风向决定发型 2024-09-01 07:53:08

嗯……苹果可能也使用 ICU 组件。最好的回应是礼貌地解释发生了什么,希望事情能顺利解决。

Hmmm...it is possible that Apple also uses ICU components. The best response would be to politely explain what's going on, and hopefully things should sort out okay.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文