ifttt支持的服务（还有更多）
ifttt的魔力：由简单组成的复杂
上面的3个例子可能稍显单薄，而ifttt的真正魔力在于“由简单组成的复杂”，也就是由众多简单的ifttt相互衔接成跨越整个互联网、跨越多平台、跨越多设备的超级自动机器。
这就跟在自然界和人类社会普遍存在的分形理论一样，无论多么复杂的大尺度的地形地貌、股市行情、社会结构都是由自相似的小尺度几何形状组成的。
回到ifttt.com，一个简单的复杂例子是，如 @hecaitou 在Twitter里所说的，理想状态下的ifttt应用场景：一旦老婆的推上出现“加班”字样，立即激活一条手机短信通知。同时，自动检测谷歌日历，找出几个今晚没有事情的老友。随后，在FB上新建一个活动“今晚喝大酒”，一旦超过3人同意，触发一条订餐消息给餐厅。餐厅查询Evernote，找到这群人最喜欢的菜和酒。
ifttt发人深省：给用户服务而不是产品和技术
ifttt解决了用户的两大问题：
一是之前的产品过于零碎、分散化，尽管云服务已经解决了单个应用的跨平台跨设备同步问题，但却不能解决产品之间的分散化问题，即单个产品只能解决用户的单个问题。如果在线下很好搞定：请一个或者多个秘书就行了，秘书能帮着搞定各种繁多的琐碎任务；但在线上反而会落后很多，各种产品间的通信和协作非常困难，比如当你的某条微博转发数达到10000次，就给你发条短信并截个图分享到推图和人人网，这样一个简单的事情都相当困难。
二是技术的复杂程度，RSS、API等为各种服务的集成提供了便利，比如Instagram就利用了Twitter的API，让用户在Instagram拍摄的图片也能分享到Twitter里，但是这又陷入了第一条所说的分散化的老问题，单个产品也只能利用其它产品的API开发出有限的服务。如果用户要自行集成各项服务以满足自己的随心所欲，那么将面临着相当复杂的技术难题，更何况没有时间，因为每个人都是普通人，我们只是想要这样随心所欲的服务而不是自己亲自动手，就这么简单。
ifttt的创始人Linden Tibbets 和Jesse Tane 正是遇到了这两大问题，才决意开发ifttt。
ifttt凭借着对用户需求的深度洞察，将所有的API调用、服务集成都挪到了后台，由ifttt的工程师和程序来处理，而面向前端用户的，就只是现成的随心所欲的服务，而且让用户像“编程”一样地设定 if … then … 的条件，让用户以极简的方式为整个互联网“编程”，运行结果就是自动化的随心所欲的服务。
事实上ifttt的理念也跟Apple前不久推出的iCloud云服务有着某种暗合，即只给用户呈现最简单的现成服务，将其它一切用户不关心的都挪到云端或是后台。（原文链接：leiphone.com/ifttt.html）
