你能想象自己开发iOS程序吗？这听起来颇为奇特，鲜有人涉足此道。然而，其中的原因，确实值得我们深入探究。
不常见的开发语言
TARGETS-iOS=iphonesimulator.x86_64 iphonesimulator.i386 iphoneos.armv7 iphoneos.armv7s iphoneos.arm64
在iOS程序开发的领域中，大家普遍使用的是特定的编程语言。比如，JavaScript、Lua、Ruby等语言在开发iOS程序时也偶有提及。然而，谈到使用开发iOS程序，却显得颇为少见。这种现象与不同编程语言的特性以及开发环境密切相关。以iOS开发为例，它拥有自己独特的工具和框架体系，使得外来语言难以顺利融入。
TARGETS-iOS=iphoneos.armv7 iphoneos.arm64
市场现状表明，针对iOS的主流编程语言已有多种解决方案可供选择。大家普遍习惯于在这些成熟的开发体系中工作，因此，在面临新的、不太熟悉的编程语言时，他们往往会表现得较为谨慎。
PYTHON_VERSION=3.4.2
编译问题
pybee开源的编译脚本看似不错，但实际使用时却常出现问题。比如，将2.7.11版本输入，编译就无法顺利进行。这种情况对开发进度造成了很大的阻碍。毕竟，如果工具本身不稳定，开发者自然不愿意使用。而且，相关文档也不够详尽。开发者遇到问题时，只能自己摸索解决，这无疑大大增加了开发的难度和风险。
pip install rubicon-objc
工程结构差异
#!/usr/bin/python
# -*- coding: utf-8 -*-
from ctypes import cdll
from ctypes import util
from rubicon.objc import ObjCClass, objc_method
# 载入Foundation框架
cdll.LoadLibrary(util.find_library(\'Foundation\'))
# 获取NSArray类
NSArray = ObjCClass(\"NSArray\")
# 等同于
# NSArray *myArray = [NSArray arrayWithObjects:@\"ok\", @\"ok1\", @\"ok2\", nil]
myArray = NSArray.arrayWithObjects_(\"ok\", \"ok1\", \"ok2\", None)
print myArray.count
print myArray.indexOfObject_(\"ok2\")
开发iOS项目时，其工程结构与直接在Xcode中创建的项目相比，差异是相当明显的。手动调整不仅繁琐，而且还得依赖模板工具。例如，使用-iOS-这类模板可以迅速搭建工程，但仍然需要进一步的调整。这种流程与常规iOS开发者的工作习惯并不相符，因此，许多开发者并不会首先考虑使用这种方法来开发iOS应用。
IDE支持不足
/**objc:**
/- (BOOL)writeToURL:(NSURL *)url atomically:(BOOL)atomically;
/**Python**
/array. writeToURL_atomically_(url, atomically)
在iOS程序的开发过程中，开发者常会遇到IDE支持不足的问题，这给他们带来了不少麻烦。例如，编写代码时缺乏objc库的提示，给开发者带来了极差的体验。毕竟，这种语言在iOS开发领域并不占主流，IDE的不便操作使得开发效率大大降低，甚至正确编写代码都变得异常困难。
系统库的使用
iOS程序的开发常常涉及到与系统库的兼容。通常情况下，当iOS程序需要实现页面功能时，UIKit几乎是不可或缺的。但实际在开发iOS程序时，处理与系统库相关的内容却变得相当棘手。需要编写一些看似是Objective-C风格却十分复杂的代码，这样的代码并不符合常规的开发需求，反而会导致工作量大幅增加。
pip install cookiecutter
解释器过大
cookiecutter https://github.com/pybee/Python-iOS-template
在开发iOS应用时，解释器的大小问题不容忽视。尤其是ARMv7和ARM64这两种解释器，其体积就超过20M，若再加上其他文件，整个包体将变得十分庞大。而与此形成鲜明对比的是，lua的解释器体积要小得多。如此庞大的解释器若被纳入生产包中，无疑会使得包体增大。在当前对软件精简度要求日益提高的背景下，这无疑是一个明显的劣势。
您认为未来iOS应用开发的的主流方向会是哪一种？若对此有独到见解，不妨留下评论，点赞并转发。
