我正在处理各种 RSS 提要，其中包含摘要以及目标页面 URL 内容，并尝试使用统一的转换方法。
XSLT 是我想到的第一个尝试的东西，因为它会以一种标准的方式完成我想要的事情，除了添加新的 XSLT 样式表以适应格式独特的网站和提要内容之外，无需大惊小怪。
问题：XSLT 库在 iOS 中被认为是“私有的”，即使静态链接到您自己的副本也会让您被 Apple Store 分析工具拒绝。
如果将样式表和数据注入到未显示的 UIWebView 中，我已经研究过这种可能性，但这似乎是一种以“已批准”的方式获取系统底层 XSLT 处理器的真正迂回和骇人听闻的方式。
存在哪些替代技术/库可以让我以标准方式做到这一点，即：不用自己动手。
我不确定我是否完全理解您的要求，但一种可能是使用libxml（iOS 中允许）来解析 XML，并在必要时操作 DOM。如果您确实需要进行 XML 转换，这将比 XSLT 付出更多的努力，但如果您只需要从 XML 中提取数据，则可以使用 xpath 查询相当容易地完成。
也就是说，我读过一些人声称他们让 XSLT 在 iOS 上运行，并且他们的应用程序在应用商店中获得了批准。特别是，我已经看到这个 stackoverflow 答案被多人声称是一个可行的解决方案。如果失败，另一个答案建议使用重命名符号自己构建 libxslt 库以绕过应用商店检查。我只建议作为最后的手段。
您可能会想研究 Hpple 以获得功能强大但重量轻/原生的东西。请参阅此处的入门教程：http ://www.raywenderlich.com/14172/how-to-parse-html-on-ios 。祝你好运！
我还将推荐 TFHpple，但我还将详细说明解决方案。我探索了一个导航第 3 方的应用程序（嗯，我是第 3 方，它们是源，但这是语义）网站/数据源，但存在一些缺陷。最大的陷阱是显而易见的：如果数据源 DOM 发生变化，您需要更改您的应用程序并重新发布。解决此问题的一种创造性方法是在公共服务器上发布/公开 DOM 的全局副本，这样最终用户不必在数据源更改时随时更新他们的应用程序（只要更改不是激进的） ）。
例如，如果您在 TFHpple 中的预期 DOM 搜索是@"//figure[@class='figure']/a"然后一周后您正在寻找的数据源的资源被更改为@"//figure1[@class='figure1']/a"您刚刚打开自己的 App Store 版本...除非...您发布预期的 DOM在您在数据字典中控制的 Web 服务器上进行搜索，您的应用可以使用该数据字典并将其提供给应用中的各种 DOM 搜索元素。我在这里预见的唯一问题是，如果数据源添加或删除您想要使用的数据元素，您要么必须发布构建，要么提前（分别）处理删除。
最后，如果数据源 DOM 的格式不正确或不一致，您可能会多次碰壁。