如果我打开包含共享扩展名中的应用程序，苹果会拒绝吗? [英] Will Apple Reject If I open containing app from share extension?

问题描述

我正在此处使用提供的解决方案从共享扩展中打开我的包含文件.尽管它很脆弱，但似乎并没有使用任何私有API方式来做到这一点.

I am using the solution provided here to open my containing from the share extension. It doesn't seem to use any private API way to do that despite that it is fragile.

如果我使用我的应用程序，苹果会拒绝吗?有人打开了包含扩展名中的应用程序的已批准应用程序吗?如果是这样，正确的方法是什么?

Will Apple reject my App if I use it? Anybody has an approved app that open containing app from share extension? If so, what is the right way to do it?

任何指针都值得赞赏.

推荐答案

尽管有很多关于如何从共享扩展中打开包含/父应用程序的问题，但实际上没有人在谈论提议的解决方案/黑客是否会被苹果或苹果公司批准.没有详细说明.

Though there are loads of questions on how to open containing/parent app from share extension, none actually talk whether the proposed solution/hack will be approved by apple or not in detail.

这样的例子是

共享扩展程序以打开包含应用程序

建议不要使用共享扩展程序来打开容器应用.

suggests that Share extensions are not supposed to open the container app.

浏览一段时间后，我宁愿找到一个非常有趣的线程来讨论同一主题

While browsing some time back, I rather found a very interesting thread discussing the same topic here

https://forums.developer.apple.com/thread/27295

线程问题，是否允许苹果使用允许通过openURL遍历UIResponder链以打开父应用程序的hack? (同样，您发布的链接中也显示了相同的想法.)

The thread questions, whether the hack of traversing UIResponder chain to open the parent app using openURL will be allowed by apple or not? (Precisely the same idea shown in your posted link as well).

尽管该线程再次没有提供明确的答案，例如它是否会被苹果公司批准，但指出了非常有效的担忧和警告

Though the thread again does not provide clear answer as, whether it will be approved by apple or not but points out a very valid concern and warning

在这里，扩展名不能使用+ [UIApplication sharedApplication]以及-openURL:这个事实，这应该是一个重要提示.忽略限制并通过Objective-C运行时查找符号不是一个好主意.

The fact that +[UIApplication sharedApplication], and hence -openURL:, is not available to extensions should be an important hint here.Ignoring that restriction and looking up the symbols via the Objective-C runtime is not a good idea.

很明显，线程暗示(隐式地，没有明确说明苹果会拒绝此类应用的事实)，尽管苹果现在会批准该应用，但这只是一个临时解决方案.

Clearly, thread suggests (implicitly, by not clearly stating the fact that apple will reject the app with such hack) that though apple will approve the app for now, it will only be a temporary solution.

现在，这终于导致了答案:

Now this finally leads to the answer:

答案:

在最近的班加罗尔苹果活动中，我有机会认识了扩展团队@apple的开发人员.我告诉他们，我一直在使用上述黑客工具从共享扩展名打开应用程序，这会被苹果允许吗?

In a recent apple event held @ Bangalore, I had an opportunity to meet the developers of extension team @ apple. I told them that I have been using the above mentioned hack to open the app from share extension will this be allowed by apple?

他的答案:

`UIResponder`

不是私有实体，因此UIResponder的使用不会违反私有API的使用条件，因此使用上述hack的应用程序仍在苹果的认可下.但是事实上，您的代码通过UIResponder链进行解析以触发openURL的代价非常高，因此不建议/不建议使用.由于Apple似乎意识到开发人员正在使用它，因此他们可能未来的应用程序. (必须说，他不确定最后一点，苹果将来会拒绝该应用程序，因此可能会突出显示)

is not a private entity, hence usage of UIResponder will not violate the private API usage condition hence apps which are using the above hacks are still being approved by apple. But the fact that, your code parses through the UIResponder chain to trigger the openURL is very costly and not suggested/preferred.As Apple seems to be aware of developer using it, they might start rejecting the app in future. (Must say, he wasn't sure of the last point, apple rejecting app in future hence highlighting might)

他还碰巧提到了WebView的用法，以打开开发人员有时也使用过的应用程序.哪个不再起作用.

He also happened to mention about usage of WebView to open the app which developers used quite sometime back as well. Which is no longer working.

结论:

是的，您可以提交使用上述技巧从扩展程序打开父应用程序的应用程序，但要完全意识到这只是一个临时解决方案，并且苹果公司希望您编写完全独立的共享扩展程序

Yes you can submit the app which opens the parent app from extension using above hack but being completely aware of the fact that this is only a temporary solution and apple expects you to write completely independent share extensions

当前iOS版本的iOS11已回答问题.答案可能会在将来的iOS版本中失去其作用

这篇关于如果我打开包含共享扩展名中的应用程序，苹果会拒绝吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！