2023年,数万技术创作者在稀土掘金碰撞灵感,沉淀分享,共同成长
他们与技术同行,与掘金同行,不断创作出高质量的技术文章,分享超前沿的技术实践
本年度人气创作者榜单开启,快来为帮助过你的创作者和技术团队投票吧!
正值 2023 年总结,掘金举办《2023年度人气创作者榜单》活动,让我们程序员狂欢的同时,其实也让优秀的开发者和团队,出现在大众的视野,出现在闪烁光芒的舞台舞台上!
所以,笔者从掘金的活动页面,梳理了人气创作者榜单,希望大家可以认识到更多优秀的开发者和团队,关注他们的文章和创新!向优秀学习,是让我们变成自己变得优秀的基础。
往届榜单:
这里收集了 68 个掘金的技术团队,排名不分先后。(注:数据收集时间截止:2023 年 12 月 25 日 0 点前。
)
这里列出了每个团队的大部分的简介,需要说的是,因为每个团队的创建时间不一样,所以文章的阅读数、点赞数、账号等级都不一定很高,大家可以根据自己的兴趣找到关注点啊~
团队图标 | 团队名 | 简介 | 标签 | 公司 | 首篇文章发表日期 | 首篇文章发表距今(天数) | 掘力值 | 掘金等级 |
---|---|---|---|---|---|---|---|---|
37手游移动客户端团队 | 我们是37手游移动客户端开发团队,致力于为游戏行业提供高质量的SDK开发服务。 技术问题/交流/进群等可以加官方微信 MobileTeam37 | - | 三七互娱 | 2020-11-07 | 1142 | 10405 | 5 | |
37手游后端团队 | 创新点亮梦想,分享成就未来,欢迎加入37手游; 📚专注后端技术,解读编程奥秘;洞察前沿技术,引领技术潮流🚀 | - | 37手游 | 2021-04-20 | 978 | 1482 | 3 | |
政采云技术 | 政采云前端 ZooTeam 团队账号已升级 政采云技术 账号,后续除前端文章外,还会发布后端 移动端 架构 质量 运维 大数据 等全工种文章 | - | 政采云有限公司@政采云技术 | 2019-08-19 | 1588 | 126540 | 7 | |
奇舞精选 | 《奇舞精选》是由奇舞团维护的前端技术社区。除周五外,每天向大家推荐一篇前端相关技术文章,每周五向大家推送汇总的奇舞周刊。 | 前端 | 奇虎360 | 2017-11-30 | 2215 | 33545 | 6 | |
古茗前端团队 | 古茗前端的技术实践分享 | - | 古茗科技 | 2023-02-17 | 310 | 12545 | 5 | |
OpenTiny社区 | 我们是华为云的 OpenTiny 开源社区,官网:opentiny.design 会定期为大家分享一些团队内部成员的技术文章或华为云社区优质博文,涉及领域主要涵盖了前端、后台的技术等。 | 华为云出品的企业级设计体系 | 华为云 | 2022-02-21 | 671 | 5203 | 4 | |
DevUI团队 | devui.design | 面向企业中后台的前端开源解决方案 | 前端组件库 | 华为 | 2020-02-26 | 1397 | 26993 | 5 | |
百度Geek说 | 公众号:百度Geek说 | 架构师 | 百度 | 2021-01-14 | 1074 | 21296 | 5 | |
货拉拉技术 | - | 货拉拉技术 | 货拉拉集团 | 2022-04-17 | 616 | 15320 | 5 | |
Dromara开源社区 | Dromara是由国内顶尖的开源项目作者共同组成的开源社区。技术栈全面开源共建,保持社区中立。目前拥有10+GVP项目,总star数量超十万,构建了上万人的开源社区,有成千上万的个人及团队在使用Dromara社区的开源项目。 | - | https://dromara.org | 2021-04-05 | 993 | 7593 | 5 | |
字节跳动技术团队 | 字节跳动的技术实践分享 | - | 字节跳动 | 2018-07-09 | 1994 | 94771 | 7 | |
vivo互联网技术 | 分享 vivo 互联网技术干货与沙龙活动,推荐最新行业动态与热门会议。欢迎 | vivo互联网技术 | vivo互联网 | 2019-03-11 | 1749 | 37477 | 6 | |
雪球工程师团队 | 团队使命:不断提升技术实力,保证质量、提高效率、完善组织,进而帮助雪球业务走向成功; 团队愿景:成为让人信赖、受人尊重、令人向往的技术团队。 | - | 雪球财经 | 2021-03-21 | 1008 | 5762 | 5 | |
网易AirtestProject | 网易游戏AirtestProject团队,开源了airtest和poco2个热门的自动化测试框架,拥有完整的自动化测试解决方案,欢迎咨询 | - | @网易,公众号:AirtestProject | 2019-11-13 | 1502 | 6676 | 5 | |
华为云开发者联盟 | 生于云,长于云,让开发者成为决定性力量 | - | - | 2020-05-06 | 1327 | 121933 | 7 | |
京东云开发者 | - | 技术运营 | 京东科技信息技术有限公司 | 2022-09-26 | 454 | 82284 | 7 | |
高灯GFE | 高灯科技GFE前端团队, 隶属于高灯科技(北京)灵工产品中心研发部,是一个富有激情、充满创造力、坚持技术驱动全面成长的团队。 | 高灯科技GFE团队 | 深圳高灯计算机科技有限公司 | 2022-02-14 | 678 | 4422 | 4 | |
MoonBit | IDEA基础软件中心打造的下一代智能开发平台 Moonbit IDE: https://try.moonbitlang.cn/ Moonbit 语法文档: moonbitlang/moonbit-syntax (github.com) Moonbit 官方网址: moonbitlang.cn | - | IDEA数字经济研究院 | 2023-06-29 | 178 | 443 | 3 | |
网易云音乐技术团队 | - | - | 网易云音乐 | 2019-07-09 | 1629 | 68972 | 6 | |
移动端小伙伴 | - | - | - | 2020-08-25 | 1216 | 2961 | 4 | |
小红书技术REDtech | “小红书技术REDtech”——小红书技术团队官方账号,小红书技术创新与问题解读的分享平台,与你共前进!不定期开展技术直播,回看请找“小红书技术REDtech”。 | - | - | 2023-04-05 | 263 | 2848 | 4 | |
洞窝技术 | 没有什么比输出开源项目来的实在。 | 技术部 | 洞窝数字 | 2023-02-09 | 318 | 2576 | 4 | |
又拍云 | - | 运维 | 又拍云 | 2017-06-04 | 2394 | 8090 | 5 | |
得物技术 | 公众号@得物技术 | - | - | 2021-01-28 | 1060 | 22012 | 5 | |
StoneDB | 企业级一体化实时 HTAP 开源数据库。 | 专业的HTAP数据库架构师团队 | 石原子科技 | 2022-06-25 | 547 | 789 | 3 | |
去哪儿技术沙龙 | - | 去哪儿旅行@公众号:Qunar技术沙龙 | 去哪儿旅行 | 2020-12-20 | 1099 | 9103 | 5 | |
葡萄城技术团队 | 葡萄城成立于 1980 年,是专业的软件开发技术和低代码平台提供商,以“ 赋能开发者”为使命,致力于通过各类软件开发工具和服务,创新开发模式,提升开发效率,推动软件产业发展,为“数字中国”建设提速。 | 公众号 | 葡萄城社区 | 2018-05-07 | 2057 | 12806 | 5 | |
袋鼠云数栈UED团队 | 创造美好的用户体验. http://ued.dtstack.cn/ | 前端开发工程师 | 袋鼠云(杭州玳数科技有限公司) | 2017-01-09 | 2540 | 5663 | 5 | |
阿里云视频云 | 「视频云技术」你最值得关注的音视频技术公众号,每周推送来自阿里云一线的实践技术文章,在这里与音视频领域一流工程师交流切磋。 | 资深算法工程师 | 阿里云 | 2020-11-04 | 1145 | 5219 | 4 | |
转转技术团队 | 转转研发中心及业界小伙伴们的技术学习交流平台,定期分享一线的实战经验及业界前沿的技术话题。 关注公众号「转转技术」,各种干货实践,欢迎交流分享~ | 公众号:转转技术 | - | 2017-08-13 | 2324 | 46820 | 6 | |
Elasticsearch | Elastic 中国社区布道师首席刘晓国 | Elastic 社区首席布道师 | Elastic | 2019-12-15 | 1470 | 31474 | 6 | |
WebRTC周刊 | 专业的 RTC 技术服务商 | 塔万小编 | 塔万科技 | 2019-08-04 | 1603 | 3551 | 4 | |
XR基地 | 让 XR 开发变得更简单! 欢迎关注微信公众号【XR基地】 | - | XR基地 | 2023-06-19 | 188 | 721 | 3 | |
CodeFuse | 蚂蚁集团自研的开源代码生成大模型。 | - | 蚂蚁集团 | 2023-10-18 | 67 | 445 | 3 | |
掘金酱 | 光吃不胖的掘金酱 | ❤首席客服君 | 掘金 | 2018-08-07 | 1965 | 78376 | 7 | |
Baihai_IDP | IDP是新一代云原生AI开发生产平台。 Github:https://github.com/BaihaiAI/IDP Gitee: https://gitee.com/baihai-idp/IDP | - | 白海科技 | 2022-06-27 | 545 | 2944 | 4 | |
汽车之家客户端前端团队 | - | - | : ) | 2019-07-21 | 1617 | 559 | 3 | |
蚂蚁集团数据体验技术 | - | 数据可视化 | 蚂蚁集团 | 2017-09-14 | 2292 | 42571 | 6 | |
字节跳动数据平台 | 赋能字节跳动各业务线,降低数据应用的门槛为始,对内支持字节绝大多数业务线,对外发布火山引擎品牌下的数据智能产品,服务行业企业客户。 | - | - | 2022-11-08 | 411 | 13413 | 5 | |
量子位 | 追踪人工智能新趋势,关注科技行业新突破 | - | 北京极客伙伴科技有限公司 | 2018-08-28 | 1944 | 12385 | 5 | |
字节跳动云原生计算 | 构建新一代海量数据计算平台 | - | 北京字节跳动科技有限公司 | 2022-06-14 | 558 | 2836 | 4 | |
KubeSphere | KubeSphere 是在 Kubernetes 之上构建的以应用为中心的多租户容器平台,提供全 | 开源的容器平台 | KubeSphere | 2019-08-01 | 1606 | 10422 | 5 | |
SkyWalking中文站 | 中文文章来自 https://skywalking.apache.org/zh/ | - | Apache SkyWalking | 2023-02-25 | 302 | 710 | 3 | |
Seal软件 | 用户友好的平台工程解决方案 | - | Seal数澈软件 | 2022-06-13 | 559 | 3982 | 4 | |
高德技术 | 关于高德的技术创新内容将呈现于此 | 高德技术团队 | 高德 | 2019-07-15 | 1623 | 4358 | 4 | |
网易云信 | 网易智企是网易旗下一站式企业服务提供商,包含网易易盾、网易云信、网易云商三大业务板块。 | 开发 | 网易智企 | 2018-06-10 | 2023 | 10928 | 5 | |
CRMEB技术团队 | CRMEB属于西安众邦网络科技有限公司旗下品牌,公司力致于利用互联网技术和思维让人们生活变得更加美好,目前主要从事客户管理+电商系统、凭借着漂亮的UI、高效整洁的代码、优质的服务获得广大用户的热爱和支持。 | 开发工程师 | 西安众邦网络科技有限公司 | 2019-03-01 | 1759 | 9596 | 5 | |
机器之心 | 专业的人工智能信息平台(www.jiqizhixin.com) | - | 机器之心 | 2017-09-05 | 2301 | 53680 | 6 | |
哈啰技术小编 | 公众号@哈啰技术 | - | 哈啰 | 2022-06-16 | 556 | 2626 | 4 | |
飞猪前端团队 | 前端技术让旅行更美好 | 公众号 | fliggyfe | 2018-01-20 | 2164 | 19162 | 5 | |
爱可生开源社区 | 成立于 2017 年,以开源高质量的运维工具、日常分享技术干货内容、持续的全国性的社区活动为社区己任;目前开源的产品有:SQL审核工具 SQLE,分布式中间件 DBLE、数据传输组件DTLE。 | 一个有深度的 MySQL 社区 | 上海爱可生信息技术股份有限公司 | 2023-06-01 | 206 | 3027 | 4 | |
ZEGO即构 | ZEGO即构科技官方账号;全球音视频云服务通信商。 | 音视频云服务通信商 | ZEGO 即构科技 | 2019-09-09 | 1567 | 3591 | 4 | |
SelectDB | 新一代实时数据仓库 | - | 北京孚莱维斯科技有限公司 | 2022-05-31 | 572 | 4175 | 4 | |
NebulaGraph | 开源分布式图数据库,千亿顶点和万亿边仅毫秒级查询延时 | 图数据库 | 欧若数网 | 2019-07-22 | 1616 | 6852 | 5 | |
字节跳动开源 | - | 运营 | 字节跳动 | 2023-03-25 | 274 | 1201 | 3 | |
ShowMeBug技术团队 | 支持实战编程的技术能力评估平台 ShowMeBug.com | - | 深圳至简天成科技有限公司 | 2021-03-28 | 1001 | 1436 | 3 | |
影子科技大前端团队 | - | - | 广州影子科技有限公司 | 2019-12-05 | 1480 | 1628 | 3 | |
LigaAI | 做更懂开发者的智能研发协作平台 | - | LigaAI | 2021-03-30 | 999 | 3816 | 4 | |
阿里云云原生 | 发布云原生技术最新资讯、汇集云原生技术最全内容,定期举办云原生活动、直播,阿里产品及用户最佳实践发布。与你并肩探索云原生技术点滴,分享你需要的云原生内容。 | 阿里云云原生公众号 | 阿里巴巴集团 | 2018-04-12 | 2082 | 71363 | 6 | |
阿里巴巴中间件 | 阿里巴巴中间件公众号(ID:阿里巴巴中间件)发布云计算干货,内容专注于微服务、serverless等全方位云原生技术内容和最佳实践,阿里专家第一视角优质原创,不定时送上直播、公开课等福利,欢迎关注 | - | - | 2018-11-26 | 1854 | 5684 | 5 | |
比心技术团队 | 技术启迪创意,想象指引实现。关注【比心技术】微信公众号。 | - | 比心 | 2023-05-21 | 217 | 626 | 3 | |
三翼鸟数字化技术团队 | 三翼鸟数字化技术团队官方号,提供技术前沿洞察、技术实践分享、最佳实践整合、技术规范发布、团队文化输出。 | - | 海尔优家智能科技(北京)有限公司 | 2023-01-17 | 341 | 710 | 3 | |
RisingWave中文开源社区 | RisingWave 是一款分布式流处理数据库。RisingWave 与 PostgreSQL 协议兼容,并提供高于 Apache Flink 十倍的性能。 | - | https://risingwave.com/ | 2022-08-28 | 483 | 698 | 3 | |
Bytebase | 开源数据库 DevOps 工具,帮助应用开发者和 DBA 管理数据库 Schema (DDL) 和数据 (DML) 的生命周期。 | - | Bytebase | 2022-08-11 | 500 | 3037 | 4 | |
openEuler | 开源操作系统openEuler 是由开放原子开源基金会(OpenAtom Foundation)孵化及运营的开源项目 | - | openEuler 社区 | 2020-08-06 | 1235 | 2154 | 4 | |
58前端技术委员会 | 58前端团队,欢迎加入我们 | 前端 | 58同城 | 2021-03-22 | 1007 | 490 | 3 | |
aeasy | 本人是深度互联网从业人员,对互联网保持高度的敏感性和关注度,在两年 | 前端工程师 | 稀土 | 2023-05-21 | 217 | 438 | 3 | |
即构开发者 | 全球云通讯服务商,帮助企业低成本轻松构建音视频服务。 | - | - | 2022-05-31 | 572 | 1115 | 3 |
而个人开发者,收集了前 300 个,基本上都是非常活跃的开发者。大家可以根据自己的兴趣找到关注点啊~ (注:数据收集时间截止:2023 年 12 月 25 日 0 点前。
)
开发者头像 | 开发者 | 简介 | 标签 | 公司 | 首篇文章发表日期 | 首篇文章发表距今(天数) | 掘力值 | 掘金等级 |
---|---|---|---|---|---|---|---|---|
iHTCboy | Learn something of everything, learn everything of something. | 移动金栈工程师 | 37 | 2021-01-08 | 1080 | 2482 | 4 | |
小满zs | 哔哩哔哩:小满zs | CEO | 小满科技 | 2021-07-29 | 878 | 15337 | 5 | |
宫水三叶的刷题日记 | 公众号: 「宫水三叶的刷题日记 」 | Software Engineer | 微软 | 2021-01-30 | 1058 | 31180 | 6 | |
why技术 | 用匠心敲代码,对每一行代码负责。 | java工程师 | 公众号【why技术】 | 2019-08-26 | 1581 | 52148 | 6 | |
若川 | 每周一起学200行左右的源码共读活动,加微信 ruochuan12 参与 | 关注@若川视野,源码共读!加Vx ruochuan12 参与 | - | 2017-07-25 | 2343 | 37991 | 6 | |
Yiko | - | - | 江西财经大学 | 2023-10-23 | 62 | 5906 | 5 | |
洛神灬殇 | 个人著作《深入浅出Java虚拟机—JVM原理与实战》。酷爱计算机科学、醉心编程技术、喜爱健身运动、热衷悬疑推理的“极客达人”。研究领域:Java领域、Spring生态、MySQL专项、微服务/分布式体系和算法设计等。 | 🏆 技术专家 | 优酷YouKu | 2021-04-13 | 985 | 25482 | 5 | |
sidiot | 💫 公众号:sidiot的技术驿站 🌈 欢迎评论区交流讨论,晚上回复 | - | - | 2022-08-31 | 480 | 20079 | 5 | |
荣达 | 一个在努力学习的菜鸟 | 实习生 | 美团 | 2023-02-08 | 319 | 4807 | 4 | |
阿豪讲Framework | 专注 Android 系统源码分析 | Android系统开发 | - | 2016-07-05 | 2728 | 6272 | 5 | |
阿杰杰杰 | 今天学习了吗 | 研发工程师 | 阿里云/北京邮电大学 | 2021-07-18 | 889 | 1309 | 3 | |
liupl | - | 上海华炎公寓 | 圆和医疗 | 2018-05-21 | 2043 | 3458 | 4 | |
月弦笙音 | 码农/人文创作者; 提笔书写诗词人生,落笔热爱代码星河 | 砖工 | 某某厂子 | 2017-11-11 | 2234 | 4677 | 4 | |
王中阳Go | 专注Go语言学习经验分享和简历优化指导。 靠敲代码在北京买房的程序员。 | 🏅掘金签约作者 | 程序员升职加薪之旅 | 2021-03-22 | 1007 | 43309 | 6 | |
Lorin洛林 | 一枚 Java 服务端码农 技术交流 技术分享 拥抱开源 开源作者 Technology has the power to make the world a better place. | Java 服务端高级开发工程师 公众号:Lorin 洛林 | - | 2023-07-20 | 157 | 5029 | 4 | |
Aidan路修远i | 前路漫漫,与君相伴 | 程序猿 | 摸鱼大队 | 2023-10-23 | 62 | 3685 | 4 | |
阳阳羊 | 加油ing | 一只小白白 | - | 2023-10-24 | 61 | 2593 | 4 | |
尘落笔记 | 笔记分享,持续学习。 “尘落笔记”(Chenluo Notes) | 前端笔记 | 上海 | 2023-04-02 | 266 | 2792 | 4 | |
AI小智 | - | - | - | 2023-04-23 | 245 | 1490 | 3 | |
BigYe程普 | AI爱好者(https://helloai.wiki); 前端工程师(NextJS、React、Vue、NodeJS); 云桌面(OVirt)。 | 前端工程师 | v:bigye_chengpu | 2018-01-11 | 2173 | 4099 | 4 | |
沐浴在曙光下的贰货道士 | CV工程师 | 前端攻城狮 | - | 2021-03-09 | 1020 | 5543 | 5 | |
minxcs | 多读书,多看报,少吃零食,多睡觉 | 在校本科大三学生 | - | 2023-10-24 | 61 | 2621 | 4 | |
Dolphin_海豚 | 大家好鸭,吃了没 | - | - | 2023-10-23 | 62 | 1911 | 4 | |
lyllovelemon | 铲屎官 | 资深前端开发 | 某不知名金融公司 | 2020-01-06 | 1448 | 9326 | 5 | |
KillerQueen | - | 在校生 | - | 2023-10-16 | 69 | 2926 | 4 | |
不简说 | 为想要入行的小伙伴打开 word 大门🚪;为刚入行的同学引领前进方向🛥;为码友们推荐奇技淫巧🚀。 虽不是资深码仔😅,乐于分享,让他人少踩坑才是好的领航员🤔 👏🏻欢迎各位转载分享😄 | 打杂码仔 | - | 2023-02-07 | 320 | 813 | 3 | |
祯民 | 一个啥都想会点的普通前端,掘金小册《SSR实战:官网开发指南》、《前端自动化测试精讲》作者 | 前端开发工程师 | 字节跳动 | 2022-09-19 | 461 | 2865 | 4 | |
iwhao | vue uniapp,爱好看电影,骑行,吉他 | 前端工程师 | 前端技术战(是战斗的战呦)@公众号 | 2020-06-15 | 1287 | 6517 | 5 | |
前端的阶梯 | - | 全栈工程师 | - | 2021-08-05 | 871 | 1171 | 3 | |
前端胖头鱼 | 会一点点前端 | FE | 公众号: 前端胖头鱼 | 2016-10-23 | 2618 | 59806 | 6 | |
一如彷徨 | 唱跳rap篮球,music! | 菜鸡前端 | 未知 | 2022-10-08 | 442 | 1715 | 3 | |
wy白菜 | 前端小菜鸟要努力变强 | web前端开发 | - | 2021-02-25 | 1032 | 862 | 3 | |
Huangyi | 路漫漫其修远兮,吾将上下而求索。 | Android开发工程师 | 华驿汽车 | 2023-08-19 | 127 | 536 | 3 | |
阿新的杂记 | 热爱后端技术的大二学生,正在努力学习中ing! 我的公众号:阿新的杂记 | 学生 | - | 2022-12-25 | 364 | 372 | 3 | |
来颗奇趣蛋 | - | 在校生 | 北京航天航空大学 | 2023-10-23 | 62 | 4374 | 4 | |
前端周公子 | 不会写代码的保洁不是一个好厨子~ V: zhoudeyou945 | 资深前端开发工程师 | 非著名👨🍳厨师专业学校 | 2018-04-14 | 2080 | 17172 | 5 | |
vaelcy | - | 前端开发工程师 | 某上市公司 | 2021-06-28 | 909 | 9403 | 5 | |
梦依小盆友 | 一个前端菜鸟 | 学生 | 东华理工大学 | 2023-10-31 | 54 | 1292 | 3 | |
田八 | - | 前端 | - | 2021-12-06 | 748 | 14425 | 5 | |
无处安放的波澜 | 喜欢分享技术、有完整视频教程、文档教程。 | 全栈工程师 | 蜗牛创想科技有限公司 | 2023-07-05 | 172 | 832 | 3 | |
前端阿彬 | 学如逆水行舟,不进则退 前端小助手:http://web-abin.gitee.io/abin-web/ | API调用工程师 | - | 2021-11-29 | 755 | 10223 | 5 | |
溪饱鱼 | 喜欢写代码,没事就写代码 | 前端开发工程师 | - | 2022-11-19 | 400 | 16634 | 5 | |
仓鼠大大 | - | 前端开发 | 腾讯 | 2021-06-09 | 928 | 1523 | 3 | |
德莱厄斯 | 懦弱之举,我绝不姑息 | 上单 | 诺克萨斯 | 2022-12-22 | 367 | 10797 | 5 | |
雾野千里 | 大三在校生 | - | 江西财经大学 | 2023-10-25 | 60 | 668 | 3 | |
MonchLee | 今天也去码头整点薯条 | 前端攻城狮 | 腾讯 | 2019-11-10 | 1505 | 4046 | 4 | |
jinzunqinjiu | - | - | - | 2023-10-27 | 58 | 873 | 3 | |
JackJiang | 开源IM框架MobileIMSDK、BeautyEye的作者。 | - | 即时通讯网 | 2017-08-22 | 2315 | 16506 | 5 | |
至臻 | - | 预备学生 | - | 2023-10-23 | 62 | 4212 | 4 | |
Lvzl | 会一点前端的打工仔 | 软件开发 | meituan | 2021-11-28 | 756 | 6261 | 5 | |
颜海镜 | 前端技术博主,《现代JavaScript库开发:原理、技术与实战》、《React状态管理与同构实战》作者 | 前端 | jsmini | 2018-09-12 | 1929 | 10942 | 5 | |
有来技术 | 公众号:有来技术 | CV/CRUD | 有来技术 | 2021-06-08 | 929 | 6023 | 5 | |
王有志 | 代码是我的文字,程序是我的诗篇,我不是程序员,我是诗人。 | 金融摸鱼侠 | 公众号:王有志 | 2020-07-06 | 1266 | 4627 | 4 | |
优弧 | 关于掘金的任何反馈都可以找我哈!可以加微信:chnyifan 或者 zwcatfly 进作者推荐群 | 管理员丨首席客服君丨运营负责人 | 掘金 | 2018-02-26 | 2127 | 24546 | 5 | |
俞凡 | 你好,我是俞凡,美资通信公司研发,对通信、网络、后端架构、云原生、DevOps、CICD等始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。 微信公众号:DeepNoMind | 研发总监 | Mavenir Systems | 2022-01-24 | 699 | 4597 | 4 | |
半夏之沫 | 喜欢编程,学习和写作 | 系统研发 | 微凉树屋 | 2023-02-03 | 324 | 6425 | 5 | |
风雨中的小七 | 想做健身博主的NLPer | NLP算法工程师 | - | 2022-07-29 | 513 | 2629 | 4 | |
布衣1983 | 一个普普通通什么都不精通的程序员! | 程序员 | geely | 2022-01-22 | 701 | 7361 | 5 | |
张风捷特烈 | 海的彼岸有我未曾见证的风采 | 万花过尽知无物 | 编程之王 | 2018-09-01 | 1940 | 59356 | 6 | |
北岛贰 | 本人文章仅在掘金发布,其它平台非授权无转载,若发现搬运或抄袭请联系我并对其进行举报,请你喝奶茶~ | web developer | 成都 | 2021-09-29 | 816 | 6613 | 5 | |
Taonce | 努力成为掘金签约选手💪 人生如梦,让我们枕着月亮。 | Android 开发 | - | 2019-05-21 | 1678 | 3453 | 4 | |
知了知了__ | 大四在读 | - | 百度 | 2023-07-13 | 164 | 1053 | 3 | |
QBorfy | 喜欢分享技术的技术人 | 前端工程师 | - | 2022-12-16 | 373 | 3970 | 4 | |
Tony沈哲 | 关注领域:Java/Kotlin 服务端、桌面端 、Android 、 机器学习、端侧智能 | 全干工程师 | 搬砖 | 2017-01-28 | 2521 | 11806 | 5 | |
终有救赎 | 月薪2800 分币不攒 就是花 | Java后端开发 | 成信大 | 2023-08-09 | 137 | 11182 | 5 | |
李小轰_Rex | 有趣的灵魂,拒绝沉默。(文章偏实战当云笔记用,主要是记录一下学习笔记与开发经验总结,希望能和大家一起交流成长。) | Flutter | Android | Mobile developer | 2021-09-09 | 836 | 4566 | 4 | |
恋猫de小郭 | 《Flutter 开发实战详解》作者,Github GSY 系列项目负责人,一个写代码的老二次猿 | Flutter & Dart GDE | 🏆 掘金签约作者 | 2016-11-14 | 2596 | 108648 | 7 | |
我真的很困 | 本科在校大学生 | 前台端盘子学徒 | - | 2023-10-29 | 56 | 517 | 3 | |
法医 | 我很荣幸成为一名前端开发者,我不是大神,但我正在为之努力! | 🏆公众号@前端猎手 | - | 2020-06-09 | 1293 | 38216 | 6 | |
只能写写代码过日子 | 我最爱代码了 ,真的 | Android | 狗不理 | 2022-01-24 | 699 | 2082 | 4 | |
虎妞先生 | 与其在别处仰望,不如来这里并肩,欢迎关注! | 公众号:天涯碧草话斜阳 | - | 2022-05-21 | 582 | 10169 | 5 | |
zhouzhouya | 前端小趴菜 | 前端开发 | - | 2022-06-16 | 556 | 1836 | 4 | |
程序员一鸣 | 耕耘于移动端,着手于前端,熟知于后端的一名全栈工程师。 | 全栈开发 | - | 2018-05-03 | 2061 | 8583 | 5 | |
寻找奶酪的mouse | 哲学:不断尝试,不断改变! 追求:认知、野心、勇气、执行力! 专业:提供简历优化和指导! | - | 👑攻粽耗:寻找奶酪的mouse | 2023-09-28 | 87 | 3230 | 4 | |
程序员大澈 | 🌍:CodeDache,添加好友一起交流学习 | 🏠公众号 | 程序员大澈,首发文章&面试礼包&进问答群 | 2022-11-05 | 414 | 3454 | 4 | |
VUE | 少年不可得之物,终将困其一生也终会因一事一景解开一生困惑 纵有万般不如意,睡得着便是过去 愿你历尽千帆归来仍是少年! | 前端开发 | - | 2023-02-11 | 316 | 1005 | 3 | |
Jay丶 | kfcvme50 | 前端开发工程师 | - | 2021-12-13 | 741 | 1751 | 3 | |
yechaoa | 掘金签约作者、CSDN博客专家、infoQ专家博主、阿里云专家博主、51CTO专家博主、华为云云享专家;现就职于阿里巴巴,研究方向包括但不限于大前端、端基础架构与中间件、性能优化等。 | 🏆掘金签约作者 | 阿里巴巴 | 2020-11-24 | 1125 | 12305 | 5 | |
猫头猫 | 随便做点有意思的事情0v0 wx公众号【一只猫头猫】 | 人形干电池 | Bytedance | 2020-10-27 | 1153 | 1247 | 3 | |
汪啊汪QAQ | 必须要成为一名酷酷的工程师 | 前端工程师 | - | 2023-03-13 | 286 | 5221 | 4 | |
sAnL1ng | Care Young | - | - | 2023-10-23 | 62 | 3878 | 4 | |
JanYork_小简 | 公众号@小简聊开发,言念君子,温其如玉。 | 全栈开发工程师 | 极致科技 | 2021-11-10 | 774 | 3225 | 4 | |
bug菌 | CSDN/阿里云/华为云/51CTO博客专家,历届博客之星Top30,掘金年度人气作者Top40,51CTO年度博主Top12,掘金/InfoQ/51CTO等社区优质创作者,全网粉丝合计10w+,硬核微信公众号「猿圈奇妙屋」,欢迎你的加入! | 公众号 | 猿圈奇妙屋 | - | 2021-10-19 | 796 | 15041 | 5 | |
summo | 越来越了解底层原理后,才发现先用好已有的东西才能创造更好的东西! | 开发/PM/PMO | 阿里巴巴 | 2022-05-30 | 573 | 4096 | 4 | |
pany | 欢迎体验开源模板 V3 Admin Vite:https://github.com/un-pany/v3-admin-vite | 前端工程师 | un-pany | 2021-02-23 | 1034 | 9178 | 5 | |
子不语Any | If not now,when? | 安卓攻城狮 | 编程美学 | 2019-11-14 | 1501 | 5145 | 4 | |
代码邮递员 | 总会越来越好的 | coding | - | 2023-05-11 | 227 | 545 | 3 | |
我是王大你是谁 | 每天进步一点点,不断提升自己,同时为行业做一点微不足道的贡献,vx:wangyansong_13 | 首席炼丹倒灶大弟子 | 宇宙尽头 | 2019-07-02 | 1636 | 30233 | 6 | |
鱼小柔 | - | 前端开发 | 网易 | 2021-04-26 | 972 | 1341 | 3 | |
Shaka | 学习,分享 | 咖啡学徒 | - | 2022-11-07 | 412 | 8830 | 5 | |
前端小张同学 | 你努力了不一定成功,但你不努力你永远不会成功。 | 前端 | xxxx科技有限公司 | 2022-04-11 | 622 | 2727 | 4 | |
小酒星小杜 | - | 洗厕所 | - | 2020-11-02 | 1147 | 1305 | 3 | |
imber | - | 前端 | 搬砖 | 2021-10-21 | 794 | 1645 | 3 | |
Ciusyan | 人生没有白走的路,你走的每一步都算数 | 还大学生呢,这不**吗~ | 滴滴出行 | 2022-07-05 | 537 | 5446 | 4 | |
知否技术 | 多学一点知识,少写一行代码。 | 公众号 | 知否技术 | 2020-12-24 | 1095 | 13789 | 5 | |
刘小灰 | 熬最深的夜,写最离谱的代码。 | 前端开发工程师 | 码不停息 | 2020-07-19 | 1253 | 6462 | 5 | |
狗头大军之江苏分军 | 狗头军狗力资源有限公司 | 狗头分军CEO | - | 2022-02-08 | 684 | 3426 | 4 | |
飞叶_前端 | 不刷算法的FE不是好工程师 | FE | - | 2018-01-03 | 2181 | 4824 | 4 | |
CookieBoty_言萧凡 | 工资到位,四皇干废 | 前端小兵成长营 | - | 2020-04-16 | 1347 | 18253 | 5 | |
萌新杰少 | Kotlin Yes | 学生 | - | 2022-07-25 | 517 | 513 | 3 | |
法的空间 | https://github.com/fluttercandies | 您的 Flutter Bug 已创建完毕,请查收 | FlutterCandies QQ群:181398081 | 2018-11-13 | 1867 | 17457 | 5 | |
九狼 | 在追逐梦想的道路上散发万丈光芒 | 学生 | - | 2021-10-02 | 813 | 4904 | 4 | |
睡醒想钱钱 | 满脑子骚操作。 | 满脑子骚操作 | 摸鱼科技 | 2018-12-13 | 1837 | 5329 | 4 | |
麦客奥德彪 | 大家好 我是麦客 我的爱好是说唱、跳舞、写代码 Music | Android 工程师 | 公司名称 | 2020-04-23 | 1340 | 7096 | 5 | |
JavaEdge在掘金 | 关注回复“面试”,白嫖大厂求职必过资源。寻创业伙伴,前端开发朋友~ | 公众号 | JavaEdge | 2018-04-08 | 2086 | 14028 | 5 | |
QdFe | 全栈 | 前端工程师 | 青岛 | 2021-09-08 | 837 | 3904 | 4 | |
前端小蜗 | - | 前端 | - | 2021-12-07 | 747 | 7444 | 5 | |
炭烤小橙微辣 | - | 前端 | 不便透露 | 2021-05-17 | 951 | 649 | 3 | |
热情的刘大爷 | 只想把我学会的所有知识,分享给所有人 | web前端 | 众安保险 | 2018-11-14 | 1866 | 9097 | 5 | |
沸羊羊你快用力推呀 | 无无无 | 火箭制造工 | 青青草原羊村 | 2022-02-16 | 676 | 744 | 3 | |
竹子爱熊猫 | 知识改变命运,学习永无止境。 | 🏆掘金签约作者 | 同名公众号:竹子爱熊猫 | 2021-06-23 | 914 | 39158 | 6 | |
FirstMrRight | 微信公众号| 种棵代码技术树 SpringCloud、Spring、MySQL、MyBatis/Plus、Redis、RocketMQ | Java开发工程师 | 青软集团 | 2021-08-11 | 865 | 2880 | 4 | |
HED | - | - | - | 2022-01-21 | 702 | 1735 | 3 | |
Swift社区 | 我们希望做一个最专业最权威的 Swift 中文社区,我们希望更多的人学习和使用Swift。我们会分享以 Swift 实战、SwiftUI、Swift 基础为核心的技术干货,欢迎您的关注与支持。 | 公众号@Swift社区 | - | 2017-12-13 | 2202 | 21437 | 5 | |
ZTStory | - | 前端、移动端开发 | - | 2022-04-27 | 606 | 1878 | 4 | |
peyton鹏 | 负责团队web、小程序、App的研发工作,负责团队管理工作,培养和完善技术人员梯队、组织培训。 | 大前端 | - | 2022-02-15 | 677 | 913 | 3 | |
言起志 | 我不懂网络,也不是完全不懂,我懂一点点 | 全栈CV工程师 | 言起志科技责任有限公司 | 2023-07-19 | 158 | 863 | 3 | |
不瑶碧莲 | Java小学生一个,多学习多努力 | Java工程师 | - | 2021-11-27 | 757 | 2034 | 4 | |
薛慕昭 | - | - | - | 2023-03-13 | 286 | 1169 | 3 | |
疯犬丨哈士奇 | - | - | - | 2023-10-24 | 61 | 345 | 3 | |
Zuo | 为热爱发电。 | 技术boy | - | 2021-03-01 | 1028 | 6500 | 5 | |
threerocks | Web 前端开发 | 从事前端项目优化、跨端解决方案研发 | 资深前端 / 架构师 | - | 2021-07-06 | 901 | 1881 | 4 | |
园宵 | 主要负责造轮子、修轮子、补胎。擅长修补扭扭车、自行车、三轮车、平板车、手扶拖拉机、量子火箭、二向箔等 | 终端开发工程师 | 稿定科技 | 2022-08-11 | 500 | 4684 | 4 | |
盐焗代码虾 | - | - | - | 2023-10-18 | 67 | 416 | 3 | |
Hyyy | - | 初级cv前端 | 某 | 2021-01-11 | 1077 | 4824 | 4 | |
xingba | - | 前端开发 | - | 2020-04-15 | 1348 | 427 | 3 | |
逍丶 | - | 前端小菜鸟 | - | 2022-05-02 | 601 | 22987 | 5 | |
Jimmy | 微信公众号:前端回眸 | 切图仔 | 某外企 | 2018-03-02 | 2123 | 45864 | 6 | |
前端老K | - | Web前端搬砖师 | - | 2020-11-22 | 1127 | 579 | 3 | |
_jiang | 好好学习 每天进步一点点 | - | - | 2021-08-20 | 856 | 1871 | 4 | |
_山海 | - | IT | - | 2023-09-28 | 87 | 2213 | 4 | |
ZED | - | 前端开发者 | 不知名工厂 | 2022-12-28 | 361 | 6281 | 5 | |
Chokcoco | 公众号:iCSS前端趣闻 | 国服第一切图仔 | Shopee | 2016-06-19 | 2744 | 130243 | 7 | |
林黛玉倒拔垂杨柳 | 前端 | - | 2021-04-21 | 977 | 649 | 3 | ||
zxhtom | 是时候底层结构了解了。不能仅仅局限于curd | 公众号 | zxhtom | 公众号,微信同名 | 2017-10-16 | 2260 | 20936 | 5 | |
几时归去做个闲人 | 📚 | 前端伴读生 | lucky pig | 2019-03-04 | 1756 | 738 | 3 | |
陈有余Tech | 技术路上的一名小学生 👨🏻💻 | Android 开发工程师 | 阿里巴巴 | 2019-10-20 | 1526 | 2893 | 4 | |
大脸怪 | Vue Naive Admin 开源项目作者 | 前端架构师 | isme.top | 2019-10-04 | 1542 | 7146 | 5 | |
酱酱_ | 大三软件工程在读 | @东华理工大学 | - | 2023-10-24 | 61 | 911 | 3 | |
陪我去看海 | 记录学习,防止遗忘 | Frontend && Gopher | 毕业即失业,求内推 | 2022-01-17 | 706 | 1699 | 3 | |
是小刘 | 数据分析 | postgraduate | gzhu | 2022-11-06 | 413 | 1363 | 3 | |
吃腻的奶油 | 我看你完全是不懂哦 | - | - | 2023-01-08 | 350 | 5619 | 5 | |
youth君 | 技术一般,我搞前端 | 💻 | 不知名小公司 | 2019-07-02 | 1636 | 5887 | 5 | |
sincenir | 基础大过天。 | 前端开发工程师 | - | 2021-03-08 | 1021 | 10024 | 5 | |
前端切圖仔 | Lee += work hard + lucky | ctrl+c ➕ ctrl+v | - | 2022-03-19 | 645 | 2466 | 4 | |
hutao | 热爱生活,热爱编程。 | 公众号 | 前端分享乐 | 2019-06-03 | 1665 | 5325 | 4 | |
durance | 20软工在读 | Java开发工程师 | - | 2023-01-14 | 344 | 622 | 3 | |
HeteroCat | 开源社区Datawhale成员 | 提示词工程师 | - | 2022-07-23 | 519 | 1123 | 3 | |
XboxYan | - | 前端侦探 | 阅文集团 | 2018-11-20 | 1860 | 28621 | 6 | |
伍六七AI编程 | 某大厂资深Java程序员,现专注于AI提效编程分享。 公众号:【伍六七AI编程】 | 资深Java程序员 | 互联网 | 2021-05-10 | 958 | 4117 | 4 | |
杨亮Jerry | 生活是一杯不加糖的espresso. | Strategist主管工程师、资深Android开发工程师 | 外企搬砖-主管工程师 | 2023-10-22 | 63 | 389 | 3 | |
forrest酱 | 初心日志,往事记录风。温柔你婆娑岁月里的花样年华 | web前端工程师 | 初心日志 | 2019-04-22 | 1707 | 5089 | 4 | |
八岁小孩学编程 | - | - | 前端实习生 百度 | 2021-11-19 | 765 | 8256 | 5 | |
蝴蝶刀砍手大师 | 这个家伙很懒什么也没留下~ | 前端 | 凯申物流 | 2019-06-26 | 1642 | 3117 | 4 | |
waynaqua | 公众号:waynblog | 全栈、Java、Javascript、Python、Php开发 | king pig | 2020-03-19 | 1375 | 19423 | 5 | |
石云升 | 凡是过往,皆为序章。 | 产品经理 | 公众号:石云升SYS | 2021-11-05 | 779 | 11462 | 5 | |
阳止零一 | - | 学生 | - | 2023-10-27 | 58 | 547 | 3 | |
LOPER7 | i love you 3000 | Android | Touch Fish | 2020-05-27 | 1306 | 1133 | 3 | |
陈明勇 | 一个热爱技术,喜欢专研技术的程序员。 个人主页:https://chenmingyong.cn。 | 后端开发工程师 | Go技术干货 | 2022-04-27 | 606 | 4736 | 4 | |
lzacking | 分享计算机基础,android,音视频,鸿蒙,C++等内容。 开源项目:https://github.com/LZacking | - | - | 2022-02-21 | 671 | 1532 | 3 | |
sowhat88 | 遇事不决挺边兵 | 前端小黄人 | - | 2023-05-01 | 237 | 559 | 3 | |
耗子君QAQ | github: https://github.com/haoziqaq | 前端开发, Varlet | 无锡某公司 | 2021-04-21 | 977 | 12147 | 5 | |
东方小月 | 日拱一卒无有尽,功不唐捐终入海 | - | - | 2021-10-13 | 802 | 16803 | 5 | |
宁在春 | 望别日,与君相见时,君已有所成。 邮箱:nzc_wyh@163.com | 👻 | Java&打杂 | 2021-07-26 | 881 | 16859 | 5 | |
J3code | 不必遗憾。若是美好,叫做精彩。若是糟糕,叫做经历。 | Java开发 | 羊城 | 2021-10-23 | 792 | 9575 | 5 | |
Zan | 有趣 | 前端架构师 | - | 2019-03-04 | 1756 | 5672 | 5 | |
蜡笔小心_ | 前端小学生,偶尔玩一点跨端技术 | 公众号『猿来是前端』 | - | 2021-12-27 | 727 | 6594 | 5 | |
别动我的代码 | 喜欢在闲(mo)暇(yu)的时候写点小玩意儿 | 前端CV工程师 | - | 2023-04-27 | 241 | 296 | 3 | |
sakana | 你努力的样子藏着父母晚年的幸福 | 修bug工程师 | 碳丝路 | 2021-10-09 | 806 | 1500 | 3 | |
吓死羊了 | - | 明天的 | 一直在学习 | 2021-01-23 | 1065 | 5406 | 4 | |
烽起黎明 | The limits of your language are the limits of your world —— 语言观决定世界观 | C/C++开发工程师 | 百度 | 2022-10-01 | 449 | 5490 | 4 | |
coder_pig | 野鸡本科结业,略懂Android、Python、搞机逆向、写过书,喜欢蕾姆,有个「抠腚男孩」的公号 | 🏆掘金签约作者 | 摸鱼王 | Android补全计划 | 2018-01-09 | 2175 | 27101 | 5 | |
苹果爸爸我爱你 | 进击的代码搬运工 | 渺小的ios程序媛 | YY | 2019-01-21 | 1798 | 1227 | 3 | |
Pokeya | Only the Paranoid Survive | 兔头不秃头 | 字节 | 2023-02-11 | 316 | 1654 | 3 | |
安卓面试官 | 公众号【安卓面试官】 欢迎关注进交流群 | 资深Android | 字节跳动 | 2016-05-15 | 2779 | 8407 | 5 | |
一只小锦李_ | 记录自己不会的小技巧,方便下次cv | CV工程师 | - | 2022-04-21 | 612 | 10410 | 5 | |
掘金归海一刀 | 心若没有栖息的地方,到哪里都是流浪. | 掘金驸马爷 | 北京北比信息技术有限公司 | 2021-08-23 | 853 | 836 | 3 | |
庸人自扰的庸人 | 世间本无事,庸人自扰之 | 一枚前端小趴菜 | - | 2022-07-17 | 525 | 13759 | 5 | |
pengboboer | android、微信小程序、flutter | - | ~~~ | 2023-04-26 | 242 | 1069 | 3 | |
gyratesky | UI设计、前端开发、产品设计 | 前端开发 | 中科智城 | 2020-10-08 | 1172 | 7242 | 5 | |
一诺滚雪球 | 故不积跬步,无以至千里;不积小流,无以成江海。 | 前端搬砖工程狮 | - | 2022-08-16 | 495 | 6742 | 5 | |
Daisy_ | 前端小辣鸡 | 前端 | - | 2022-08-09 | 502 | 490 | 3 | |
廖小新 | 一枚喜欢分享技术的前端er,可以关注我一起交流学习 | 公众号@ 小新的前端笔记 | - | 2016-10-07 | 2634 | 1198 | 3 | |
岩浆李的游鱼leo2 | 懂的越多,不懂的也越多 | 上海Android、前端开发 | 正在上市中… | 2019-07-10 | 1628 | 7556 | 5 | |
Conqueror712 | 于高山之巅,方见大河奔涌;于群峰之上,更觉长风浩荡。 | 🏆掘金签约作者丨📖学生 | BUPT | 2023-01-12 | 346 | 3156 | 4 | |
zxg_神说要有光 | 小册《Nest 通关秘籍》《前端调试通关秘籍》《TypeScript 类型体操通关秘籍》《Babel 插件通关秘籍》作者 | 神光的编程秘籍 | - | 2019-02-17 | 1771 | 138845 | 7 | |
托儿所夜十三 | 摸鱼选手在线摸鱼 | 🏆公众号 | 托儿所的前端秘籍 | 没有事科技公司 | 2018-05-16 | 2048 | 6021 | 5 | |
俊劫 | 加我进摸鱼群(我吴某人与毒赌不共戴天) | CV战士 | JJ | 2019-02-13 | 1775 | 27062 | 5 | |
猪头切图仔 | 分享些成长路上的所见所闻所思所得。 | - | - | 2023-04-21 | 247 | 2148 | 4 | |
紫衣小生 | 做好该做的。 | 前端 | 珠峰电梯改造项目组 | 2021-04-28 | 970 | 2519 | 4 | |
知行合一也 | 纸上得来终觉浅,绝知此事要躬行 | 前端开发工程师 | - | 2023-03-21 | 278 | 670 | 3 | |
努力的小雨 | 一枚四年 Java 服务端码农 热爱AI | 技术交流 | 技术分享|拥抱开源 | 公号 |【灵墨AI探索室】 | - | 2023-04-20 | 248 | 4647 | 4 | |
Captaincc | 寻找优质内容创作者ing 有任何关于掘金的问题可以咨询我微信:229199157 | 问题解决官 | juejin.cn | 2021-10-12 | 803 | 1994 | 4 | |
大漠_w3cpluscom | 大漠,W3CPlus 创始人,曾就职于淘宝。《现代 CSS》、《现代 Web 布局》、《防御式 CSS 精讲》和《Web 动画之旅》的作者!对 HTML、CSS 和 A11Y 等领域有一定的认识和丰富的实践经验。CSS 中国布道者! | 前端技术专家 | - | 2019-05-17 | 1682 | 3936 | 4 | |
lin嘟嘟嘟 | - | 前端开发 | - | 2020-10-15 | 1165 | 6197 | 5 | |
Recently祝祝 | 不认命就拼命,脚踏实地,稳步前行 | - | - | 2023-04-09 | 259 | 1552 | 3 | |
坚果派_xq9527 | Android flutter Java EE 鸿蒙 | android 开发 | 网易 | 2020-03-26 | 1368 | 3781 | 4 | |
阿杆 | 一个无聊时会打打游戏或者写写文章的程序员🤡,欢迎关注我的公众号【程序员阿杆】🎉。 | Java后端 | - | 2022-08-23 | 488 | 15198 | 5 | |
闲坐含香咀翠 | 想进大厂! | 学生 | 浙江科技大学 | 2022-05-18 | 585 | 472 | 3 | |
Mio_02 | - | 大三在校生一枚~ | - | 2023-10-30 | 55 | 493 | 3 | |
志字辈小蚂蚁 | - | 公众号 :志字辈小蚂蚁 | 武汉 | 2020-07-27 | 1245 | 17203 | 5 | |
滚去睡觉 | 大三 软件工程专业 | - | - | 2023-11-09 | 45 | 1840 | 4 | |
程序员凌览 | 会当凌绝顶,一览众山小 | 公粽号:程序员凌览 | - | 2021-06-30 | 907 | 5701 | 5 | |
帅的名称都被抢了 | 希望通过写文章来锻炼自己的写作能力、表达能力、知识收集以及整理能力,大家一起持续成长呀! | web前端开发 | - | 2022-03-22 | 642 | 1517 | 3 | |
陇锦 | WeChat:ljsw8686 | web前端 | 切图仔 | 2018-06-20 | 2013 | 5206 | 4 | |
阳树阳树 | 要失业了咋办哪 | - | 25届前端er 春招求推荐 | 2022-02-24 | 668 | 8377 | 5 | |
糖墨夕 | 光之晨曦 | FE | NestJS | 2022-12-28 | 361 | 8862 | 5 | |
在下uptown | - | 夹娃练习生 | - | 2022-04-19 | 614 | 4320 | 4 | |
齐舞647 | 95后,喜欢研究各类技术,目前就职于掘金。内推链接:https://juejin.cn/post/7172204499094732830 | 工程师 | 掘金 | 2019-12-28 | 1457 | 4915 | 4 | |
CN千石 | 一个喜欢哲学、二次元の某不知名Gopher To be better! | 某不知名のGopher && 大三学生 | - | 2022-07-24 | 518 | 2720 | 4 | |
搬砖的乔布梭 | - | 前端架构师,全栈工程师 | - | 2022-05-08 | 595 | 5375 | 4 | |
苏苏哇哈哈 | 宇宙无敌超美少女程序员 | 前端 | 公众号:苏苏的BUG | - | 2021-09-30 | 815 | 4684 | 4 | |
Sunshine_Lin | 一名Rapper,一位历史迷,一位前端菜鸟 | - | 公众号:前端之神 & B站:林三心的挖掘机 | 2020-06-02 | 1300 | 133105 | 7 | |
染念 | Big高性能计算、small前端… | 研one | 电专 | 2023-01-17 | 341 | 299 | 3 | |
沐洒 | 一个有极度表达欲望的,曾经文艺过的代码工匠,用你看得懂的文字,帮你把这个世界讲通透。 | 高级前端开发 | 腾讯 | 2023-02-23 | 304 | 4593 | 4 | |
Mr_绍君 | 搬砖人 https://github.com/yeshaojun | 前端工程师 | 宁波搬砖有限公司 | 2022-01-10 | 713 | 1459 | 3 | |
RiemannHypo | 微信号JingnanSJ或者公众号RiemannHypo获取异步和图灵系列书籍, | Full Stack | RiemannHypo | 2021-12-10 | 744 | 15880 | 5 | |
Anguers | 路虽远行则将至,事虽难做则必成! | web、Flutter 开发工程师 | 西安 | 2022-03-03 | 661 | 424 | 3 | |
腌肉要轻轻拍打 | 和印总裁陆景和唯一指定的和印大数据中心前端工程师 | 前端 | - | 2023-02-08 | 319 | 356 | 3 | |
JasonChen | 自律以修身,自省以观己,自学以长识,自处以蓄力 | 米其林主厨 | - | 2022-09-22 | 458 | 625 | 3 | |
草帽lufei | 用计算机创造美和艺术,用代码改变世界。 | 攻城狮 | 北京xxx公司 | 2020-01-14 | 1440 | 8776 | 5 | |
抢老婆酸奶的小肥仔 | 没有搞不懂的技术,只有搞不懂的人 | java开发 | - | 2023-04-25 | 243 | 2904 | 4 | |
会飞的喵喵 | 对于我们控制范围以内的事情要足够的谨慎,对于我们控制范围以外的事情要有足够的信心。 | 学生 | - | 2022-12-14 | 375 | 1991 | 4 | |
子洋 | 须知少时凌云志,曾许人间第一流。 | 前端开发工程师 | 公众号:子洋的摘星阁 | 2021-05-10 | 958 | 982 | 3 | |
margin_100px | 𝓕𝓻𝓸𝓷𝓽-𝓮𝓷𝓭 𝓭𝓮𝓿𝓮𝓵𝓸𝓹𝓶𝓮𝓷𝓽 | 𝓶𝓪𝓻𝓰𝓲𝓷 𝟭𝟬𝟬𝓹𝔁 | - | 2022-12-13 | 376 | 3545 | 4 | |
晴天小庭 | 《安卓现代化开发手册》作者,详情:https://yang961226.github.io/ | 菜鸟级安卓工程师 | 广州某作坊 | 2022-06-01 | 571 | 3148 | 4 | |
九酒 | 一直在走神 | 前端练习生 | - | 2018-03-31 | 2094 | 2353 | 4 | |
灵扁扁 | 我看青山多妩媚,料青山见我应如是。 | 一线开发 | - | 2022-03-31 | 633 | 20446 | 5 | |
Y_d | 让正确的事情持续发生 | 前端开发 | - | 2023-07-10 | 167 | 787 | 3 | |
山间小僧 | 微信公众号:山间小僧 | 正儿八经的程序员 | - | 2020-04-28 | 1335 | 1670 | 3 | |
桑小榆呀 | 关注公众号:桑小榆呀 致力于业余热爱,每一篇都是在认真创作 | 马斯克助理 | 公众号:桑小榆呀 | 2022-06-26 | 546 | 8331 | 5 | |
汪汪队长 | 汪汪队招募新人 欢迎加入 BUG+CV攻城狮 | 狗头协会CEO | 狗头协会 | 2021-12-27 | 727 | 469 | 3 | |
阿钟 | 上辈子作恶多端,这辈子写前端。 | Hello World全栈工程师 | - | 2016-11-07 | 2603 | 1263 | 3 | |
Spirited_Away | - | 前端应届生 | 上海某公司 | 2020-05-13 | 1320 | 18706 | 5 | |
拖孩 | 咸鱼 | 前端 | 万店掌 | 2022-07-13 | 529 | 1490 | 3 | |
编程小工匠 | 一个热爱编程和技术的小伙子。我在掘金社区中主要关注和学习移动端开发相关的技术和工具,同时也会分享一些自己的学习心得和经验。希望能够在社区中结交更多志同道合的朋友,一起学习、交流和成长! | 移动端开发工程师 | - | 2023-02-20 | 307 | 313 | 3 | |
UOrb | 🏆掘金签约作者 | 前端 | - | 2019-11-18 | 1497 | 2677 | 4 | |
悲伤周杰伦 | - | - | - | 2023-09-17 | 98 | 348 | 3 | |
ChenYhong | - | Android开发工程师 | MiniGame | 2021-11-06 | 778 | 5713 | 5 | |
大神仙 | sleep | - | - | 2019-10-22 | 1524 | 532 | 3 | |
乔明飞 | 拥抱知识开源,共享学习成果 | 架构师 | 智线云科技有限公司 | 2023-09-21 | 94 | 1120 | 3 | |
Shengmax | 一个合格的前端不仅要会后端,还要会设计,测试,运维,优化。这还不够,还要会做饭,会运动,会休息,会取悦自己。不然生活会很苦… | 全栈开发 | - | 2022-10-12 | 438 | 2841 | 4 | |
小杜杜 | 《玩转 React Hooks》小册已上线,一起实现 React 进阶吧! | 🏆掘金签约作者 | 公众号:杜杜的全栈之旅 | 2020-11-10 | 1139 | 30989 | 6 | |
linwu | ☀高级前端开发工程师 🌲就职于腾讯等多家互联网大厂 📚《现代Javascript高级教程》、《现代Typescript高级教程》、《深入浅出Dart》作者 | 高级前端开发工程师 | 腾讯 | 2023-06-21 | 186 | 18073 | 5 | |
前端随想 | 喜爱前端技术,热爱前端开发 | 学生 | 无 | 2023-04-18 | 250 | 1594 | 3 | |
Data_Adventure | 碎冰深入梦,细雨拂身清。 思考数据之美,独步古今情。 视觉化如画,故事点滴呈。 铃声伴旋律,编码随心行。 | 数据冒险家 | - | 2021-10-25 | 790 | 4958 | 4 | |
Onion | - | 前端小白 | 蔡莱网络 | 2021-10-16 | 799 | 3111 | 4 | |
谋爱先谋生爱人先爱己 | Android、Flutter、iOS | 移动端高级工程师 | 东软睿驰汽车技术有限公司 | 2020-08-09 | 1232 | 11995 | 5 | |
前端小付 | 很喜欢deft在夺冠时说的一句话:我唯一会的仅剩英雄联盟,如果在这条路上我不能成功,那我的人生将没有任何意义。 我唯一会的就是写代码,我不一定能成功,但是我也会努力做到更好。 | 前端架构师 | - | 2018-08-20 | 1952 | 12164 | 5 | |
幸运是我 | 前端开发 | 前端开发工程师 | 美团众包 | 2023-05-06 | 232 | 1114 | 3 | |
遨游在代码海洋的鱼 | 旱鱼 | Android开发 | - | 2022-12-07 | 382 | 457 | 3 | |
crossoverJie | Javaer Gopher | Gopher | 公众号『crossoverJie』 | 2016-07-14 | 2719 | 36008 | 6 | |
一起随缘 | 一个自恋的程序员 | java开发工程师 | - | 2021-03-14 | 1015 | 2889 | 4 | |
曾经的你d | - | 前端开发工程师 | - | 2022-03-22 | 642 | 934 | 3 | |
coderSlow | 一个保持终身学习态度的前端开发工程师 | web前端工程师 | 某数字科技有限公司 | 2021-06-06 | 931 | 2100 | 4 | |
liruifengv | 全栈/技术博主/开源爱好者/Deno 贡献者/Astro 贡献者/Astro 中文文档译者 | 前端工程师 | 某公司 | 2017-06-05 | 2393 | 10061 | 5 | |
谦宇 | 小册《前端可视化入门与实战》作者,公众号: 谦宇的编程世界 | 资深前端工程师、专攻于可视化 | - | 2022-05-07 | 596 | 10946 | 5 | |
吴彦祖火星分祖 | 想让世界充满爱… | Eat,Sleep,Code | 汽车之家 | autohome | 2023-04-05 | 263 | 510 | 3 | |
JiKun | - | web前端工程师 | 上海某不知名公司 | 2019-08-30 | 1577 | 3167 | 4 | |
一条会coding的Shark | 热爱摸鱼~ 欢迎来摸~ 个人博客: https://xusssyyy.github.io/blog/ | 前端 | - | 2022-04-25 | 608 | 8533 | 5 | |
修之竹子 | 公众号【修之竹】关注Android 技术,还有成长道路上的点滴记录、思考,欢迎关注,与我一同成长,一同收获幸福~ 微信号 xiuzhizhu ~ | Android 公众号 @修之竹 | - | 2021-07-23 | 884 | 1041 | 3 | |
唐志远 | https://fe32.top | 两年半的FE | - | 2021-05-21 | 947 | 4179 | 4 | |
顾昂_ | 积淀,如麦熟雨落,静默却磅礴 | 寻找生活 | - | 2019-11-16 | 1499 | 4098 | 4 | |
前端南玖 | 微信:NANJIU-SY | 公众号:前端南玖 | - | 2021-03-15 | 1014 | 25787 | 5 | |
毅航 | 始于源码,但不止于源码,主研后端,爱好前端。尽己所能,讲透技术! 公众号:毅航漫谈 | 😇六十九岁扶墙开发 | 🌴@二年半 | 2021-08-01 | 875 | 6660 | 5 | |
前端笨鸟 | - | - | - | 2021-07-19 | 888 | 2881 | 4 | |
oversize的前端男孩 | 被记住的只有天才和疯子 | 25届前端鳄鱼 | 百度YY | - | 2022-07-18 | 524 | 1436 | 3 | |
初露寒秋 | java后端开发,趋于蓝色的性格。保持感性的思绪和触动,贯彻理性的内涵和想法。孤灯烟影 初露寒秋。 | 资深软件开发工程师 | - | 2017-02-25 | 2493 | 3534 | 4 | |
宁轩 | 点赞小能手帮我赞一下文章, 有赞必回 | - | - | 2022-05-29 | 574 | 5068 | 4 | |
旅梦开发团 | - | 前端工程师 | 旅梦开发团 | 2019-01-31 | 1788 | 3327 | 4 | |
菠萝的蜜 | - | FE | - | 2019-05-21 | 1678 | 4989 | 4 | |
9号达人 | - | - | - | 2022-03-11 | 653 | 339 | 3 | |
老A说 | 作为大厂面试官,助你轻松应对Android面试官的连环炮 | 百度-资深研发工程师 | 百度 | 2023-11-27 | 27 | 555 | 3 | |
萌萌哒草头将军 | VX公众号『萌萌哒草头将军』,欢迎关注 | 前端开发 | - | 2019-06-30 | 1638 | 20749 | 5 | |
demo007x | 拥有 10+年的互联网 web 开发经验,掌握web 开发的相关技能和技巧。团队管理,架构设计,规范制订及实施。多年TOB 企业、教育行业经验。 | - | 公众号:知识派 | 2017-11-02 | 2243 | 6303 | 5 | |
Palp1tate | Talk is cheap. Show me the code. | 软件工程 | 电子科技大学 | 2023-05-07 | 231 | 1948 | 4 | |
大流星 | 备份博客:https://github.com/AttemptWeb/Record/issues | 前端 | https://herrylo.github.io/front/ | 2018-12-03 | 1847 | 5513 | 5 | |
野生程序猿江辰 | 前网易高级前端开发工程师 | 矩阵创始人 | 独立开发者 5年+前端开发经验 | 大前端方向 | 微信小程序 | H5 | Web 公众号:野生程序猿江辰 | 高级前端开发工程师 | 找工作中 | 2018-03-26 | 2099 | 7150 | 5 | |
deepCode | - | 全栈开发 | - | 2022-03-16 | 648 | 2670 | 4 | |
vipbic | 嘿,我是前端小羊,点击上方查看我的主页,https://github.com/hangjob | web开发工程师 | - | 2018-01-04 | 2180 | 5051 | 4 | |
游向远方 | 用心创作,用爱丰收。 | 前端开发 | - | 2023-06-01 | 206 | 879 | 3 | |
流口水的兔子 | - | 前端工程师 | - | 2022-07-04 | 538 | 812 | 3 | |
巫山老妖 | 腾讯高级客户端工程师,技术栈:Android、Java/Kotlin、Linux、C/C++、Python。知乎/公众号:巫山老妖 | Android高级工程师 | 腾讯 | 2016-09-23 | 2648 | 2776 | 4 | |
DaveCui | 数据分析,软件开发,机器学习爱好者 | 大数据开发工程师 | SQL Boys | 2022-10-02 | 448 | 5635 | 5 | |
Ensoleile | - | cv工程师 | 卷王家族 | - | 2023-05-22 | 216 | 321 | 3 | |
玖月晴空 | 喜欢和一群有趣的人做一些有意义的事情。 | 前端工程师 | 外研社 | 2017-11-19 | 2226 | 8137 | 5 | |
依旧_99 | - | CV大牛 | - | 2022-12-12 | 377 | 2726 | 4 | |
ArvinC | Stay hungry Stay foolish & Code | 前端攻城狮💥 | - | 2021-04-09 | 989 | 4949 | 4 | |
南山种子外卖跑手 | 仰望星空,脚踏实地,逐步前行! | 🏆掘金签约作者 | 腾讯 | 2022-01-12 | 711 | 6772 | 5 | |
shortybin | - | Android工程师 | - | 2017-08-08 | 2329 | 602 | 3 | |
玛奇玛丶 | 在内卷与躺平中挣扎 | java咸鱼工程师 | - | 2023-02-28 | 299 | 900 | 3 | |
二当家的白帽子 | 一起加油吧,希望我们大家都能每天进步一点点,成为我们想要成为的那个人~~~~~ | 高级系统架构师 | - | 2021-08-08 | 868 | 5685 | 5 | |
矢心 | js、vue、electron、uniapp | 前端开发 | 广东联塑 | 2023-04-16 | 252 | 1305 | 3 | |
叶一一 | 追风赶月莫停留,平芜尽处是春山。 | 趣学前端 | - | 2021-08-16 | 860 | 10460 | 5 | |
菜菜的后端私房菜 | 专注Java后端技术栈,热爱工作,热爱生活,关注菜菜,分享更多干货日常哟 | 公众号:菜菜的后端私房菜 | - | 2022-05-15 | 588 | 4743 | 4 | |
SmileNicky | java程序员 | Java程序员 | - | 2017-04-04 | 2455 | 5184 | 4 | |
shepherd111 | 分享点点滴滴,滴水穿石 | 后端开发 | - | 2023-03-16 | 283 | 5465 | 4 | |
热爱编程的小白白 | - | - | - | 2022-08-02 | 509 | 467 | 3 | |
吃什么 | 不要问我吃什么(゚o゚; | 前端背锅侠 | 金麟岂是池中物 | 2023-02-20 | 307 | 939 | 3 | |
南城FE | 公众号:南城大前端(ID: nanchengfe),分享前端相关技术干货 | 前端 | 深圳 | 2022-04-27 | 606 | 18334 | 5 | |
IT_陈寒 | 大家好,我是[IT.陈寒],CSDN内容合伙人、全栈领域优质创作者,华为云特邀云享专家,阿里云专家博主、星级博主,51CTO明日之星,热爱技术和分享,欢迎来到我的博客空间!!! | Java开发工程师 | 奇酷网络有限公司 | 2023-08-14 | 132 | 965 | 3 |
一年过去了,相比去年的创作者榜单,会发现大多数创作者依然还在坚持,也有一些新人加入,让技术分享更加动人。当我看到优秀文章内容的时候,总是喜笑颜开,欣喜若狂!惊叹技术知识的原理如此严谨又有趣,也发现有些作者文笔非常的秀丽,像是爽文又是佳文,衷心的感谢~ 那种感觉大家应该都体会过,所以,希望本文可以让大家能收获到一些优秀的创作者,不要再说没有学习资源!
感谢掘金举办的这次活动,让开发者欢聚一堂,同时也让活跃的开发者呈现在大家面前,最后,向 2023 年说声谢谢,说声再见!我们来过,我们走了,往更加美好的 2024 年出发!
本文首发于 苹果 iOS 分发和安装 App 的那些趣事 - 掘金,欢迎关注我们 @37手游移动客户端团队 。
作者:iHTCboy
本文介绍了苹果iOS应用分发和安装的一些有趣的事。讨论了不同的开发者计划和分发方式,包括企业签名、超级签名、TestFlight签名和MDM超级签名。还提到了开发者模式、企业账号、设备注册限制以及自定App和非公开App分发的解决方案。最后,讨论了欧盟的《数字市场法》对苹果的影响和可能改变苹果软件生态的可能性。
2007 年第一代 iPhoneOS 并不支持给 iPhone 开发原生应用,当时苹果主推 Web Apps,然而,一些技术爱好者探索越狱(Jailbreak)iPhone 的方法,这意味着可以拿到操作系统的管理员权限,从而能够安装第三方应用程序。越狱使得 iPhone 用户能够访问非官方应用商店,以及自定义铃声、壁纸和其他功能。
2008 年 3 月 6 日,苹果 CEO 史蒂夫·乔布斯 公布了 iPhone 软件路线图,正式宣布推出 App Store 应用商店!
图片来自 web.archive.org
乔布斯说:“我们很高兴创建一个充满活力的第三方开发人员社区,该社区可以为 iPhone 和 iPod touch 提供数千个原生应用程序。iPhone 的企业功能与其革命性的多点触控用户界面和先进的软件架构相结合,为移动设备提供了有史以来最好的用户体验和有史以来最先进的软件平台。”
至此,开启了苹果至今 15 年的 App Store 商业帝国的征程,iPhone Software Roadmap 奠定了苹果开发者的第三个方向:
注:本文不会讲解苹果在 iPhone 上如何限制安装 App 的技术原理,网上已经有很多文章,大家可以自行搜索。只会讲解苹果分发 App 方式的演变过程,让所有小白都能快速知道!
iPhone 软件路线图发布会后,苹果开放了 iPhone 企业测试版计划,并不是所有开发者都能符合要求,在测试期间提供给数量有限的开发者。需要申请此计划有 5 个要求:
图片来自 web.archive.org
此外,只有美国的公司有资格申请,当时的申请表,罗列了一系统详细的问卷,如贵公司从事的行业?使用哪些运营商网络?贵公司支持哪些邮件服务器?贵公司支持哪些协议的 VPN?
所以,最开始只允许 5 台真机安装测试 App。
The iPhone Developer Program provides a complete and integrated process for developing, debugging, and distributing your free, commercial, or in-house applications for iPhone and iPod touch. Complete with development resources, real-world testing on iPhone, and distribution on the App Store, you have everything you need to go from code to customer.
iPhone 开发者计划提供了一个完整的集成流程,用于开发、调试和分发 iPhone 和 iPod touch 的免费、商业或内部应用程序。凭借开发资源、iPhone 上的实际测试以及 App Store 上的分发,您拥有从代码到客户所需的一切。
iPhone 开发者计划提供 2 个计划方案:
图片来自 web.archive.org
2 个计划方案的区别:
标准计划 | 企业计划 | |
---|---|---|
年费 | $99 | $299 |
申请要求 | - | 500+员工 |
iPhone SDK | ✔️ | ✔️ |
iPhone 开发者资源 | ✔️ | ✔️ |
iPhone 和 iPoad touch 真机测试 | ✔️ | ✔️ |
代码级技术支持 | ✔️ | ✔️ |
苹果开发者论坛 | ✔️ | ✔️ |
App Store 分发 | ✔️ | ✖️ |
Ad Hoc(临时)分发 | ✔️ | ✔️ |
In-house(内部)分发 | ✖️ | ✔️ |
iPhone 和 iPoad touch 真机测试 | 各100台 | - |
这里的 Standard Program(标准计划)就是现在咱们说的开发者(个人或公司),Enterprise Program(企业计划)是企业开发者,他们的区别,从上面能直观看出来,标准计划是用于上架 App Store,而企业计划目的是给企业内部分发 App 使用。
所以,从一开始,苹果就已经明确开发者 iPhone 和 iPoad touch 真机测试只能使用最多各 100 台安装测试的 App。而企业计划不限制 App 分发的设备数,可安装在任意设备上。当然 App Store 也不限制 App 下载的设备。
这里一定很多人会问,大家怎么这么傻:用 Enterprise Program(企业计划)就不用给苹果交 30% 分成了?其实,苹果应用内购买当时还没有提出,并且后来 App Store 非常成功,对于开发者不需要自己进行推广,在当时是非常省心省力的,苹果内购的历史可查看之前的文章《关于 App Store 苹果商店价格的那些事》。
The iPhone Developer University Program is a free program designed for higher education institutions looking to introduce curriculum for developing iPhone or iPod touch applications. The University Program provides a wealth of development resources, sophisticated tools for testing and debugging, and the ability to share applications within the same development team. Institutions can also submit applications for distribution in the App Store.
iPhone 开发者大学计划是一个免费计划,专为希望引入开发 iPhone 或 iPod touch 应用程序的课程的高等教育机构设计。大学计划提供了丰富的开发资源,复杂的测试和调试工具,以及在同一开发团队中共享应用程序的能力。机构也可以在 App Store 中提交分发申请。
图片来自 web.archive.org
iPhone 开发者大学计划有什么不同?其中可以理解为是免费版的 Standard Program(标准计划),不需要年费!所以能安装和分发的设备数,是一样的。(注:现在的开发者大学计划分发规则已经更改,详见下文介绍。)
这里也可以看出来,苹果对于吸引大学生的计划,从一开始就已经意识到,大学生的创造力是无限的!
综上,iPhoneOS 2 苹果允许分发和安装 App 的方法:
2010 年 6 月 7 日的 WWDC2010 乔布斯宣布,将原来 iPhone OS
系统重新定名为 iOS
,并发布新一代操作系统:“iOS 4”。
所以,正式开启 iOS 时代:iOS Developer Program
!
2014 年 7 月 22 日,苹果在 App Store 上架了一款 TestFlight App ,允许 1000 名测试人员安装 App。
TestFlight 是 Burstly 公司推出的在线安装和测试移动应用的平台,最初支持对 Android 和 iOS 应用程序进行测试,苹果于 2014 年 2 月收购了 Burstly,并在 2014 年 3 月撤销了对 Android 的支持。
最开始 TestFlight 大家并没有使用,一方面安装只有 90 天的有效期,到期后 App 就打不开,并且开发者更新新版本,另一方面最开始只支持 1000 名测试人员。后来,2016 年,增加到 2000 名测试人员额度,2017 年增加到 10000 名,以支持更大规模的 Beta 测试。
现在,TestFlight 可让你轻松测试 iOS、iPadOS、macOS、Apple tvOS、watchOS 和 iMessage 信息 App 的 Beta 版本以及轻 App,并在开发者将 App 发布到 App Store 前为他们提供有价值的反馈。开发者会通过电子邮件或公开链接邀请测试人员。详见 TestFlight 官网。
如今,TestFlight 测试已经成了没有上架 App Store 的 App 分发和安装的方案:
测试员 | 安装名额 | 使用有效期 | 优点 | 缺点 |
---|---|---|---|---|
内部 | 25名 | 90天 | 1. 稳定可靠,不需要用户点击配置或信任证书 2. 新版本可用时,自动通知或自动安装更新 | 1. 90天有效时间过短,1万名额度可能还不够 2. 测试人员需要安装 TestFlight App |
外部 | 10000名 | 90天 | 同上 | 同上 |
“一个会员资格,无限的可能性”
2015 年 6 月 8 日 WWDC2015,苹果整合自家的开发者计划:
Apple Developer Program
,不在需要分别付费,只需要付费一次 $99。Apple Developer Free Account
(免费个人开发者),普通 Apple ID 账号就可以使用苹果开发和真机测试。免费个人开发者,需要在 Xcode 7 中导航到 “Xcode -> Preferences —> Accounts”,点击左下方的 “+” 图标添加 Apple ID 登陆,就可以进行真机调试,前提是需要在 苹果开发者官网 注册和同意协议。
但是需要注意,同年推出的 iOS 9,开发者用免费个人开发者进行真机安装测试 App 时,会提示 “不受信任的开发者”
xxxx:
需要先信任才能打开,具体在 “设置 -> 通用 -> VPN 与设备管理” 中找到 “开发者 App”,然后找到你需要安装的 App,点击 “信任” 即可。
区别总结:
账号类型 | 安装名额 | 使用有效期 | 优点 | 缺点 |
---|---|---|---|---|
Apple Developer Program(苹果开发者计划) | 100 台 | 365天(一年) | 1. 有效时间相对较长 2. 允许安装设备多 | 1. 收费 $99 |
Apple Developer Free Account(免费个人开发者) | 3 台 | 7天 | 1. 免费 | 1. 有效时间短 2. 安装麻烦 |
同样的,2015 年推出的 iOS 9 对企业证书的 App 也进行了调整:
在 iOS 8+ 系统时,虽然苹果会提示“不受信任的应用程序开发者”,但是用户点击 “信任” 按钮后,就可以打开 App,非常方便。
而 iOS 9.0 系统后,也是需要在设置里授权,才能打开。
至此,苹果开发者账号的已经完成统一:
Apple Developer
:已同意《Apple 开发者协议》以访问 Apple Developer 网站上特定资源的 Apple ID 持有者。此为免费协议,但开发者无法分发 App。ADP
:Apple Developer Program 会员资格。此付费计划的会员可以在 App Store 上分发 App。ADEP
:Apple Developer Enterprise Program 会员资格。此付费计划的会员可以在组织内部向员工分发 App。关于账号支持的功能和资源,可以参考官网: 支持的功能 (iOS) 。
总结苹果开发者账号:
账号类型 | 安装名额 | 使用有效期 | 优点 | 缺点 |
---|---|---|---|---|
Apple Developer Free Account(免费个人开发者) | 3 台 | 7天 | 1. 免费 | 1. 有效时间短 2. 安装麻烦 3. 不能上架 App Store |
Apple Developer Program(苹果开发者计划) | 100 台 | 365天(一年) | 1. 有效时间相对较长 2. 允许安装设备多 3. 可以上架 App Store | 1. 收费 $99 |
Apple Developer Enterprise Program(苹果开发者企业计划) | 无限 | 365天(一年) | 1. 有效时间相对较长 2. 允许安装设备无限 | 1. 收费 $299 2. 不能上架 App Store |
这个大学计划,与最开始的区别是,不能在上架 App Store,其它的区别不大,还是免费的账号。
以下是官网的 FAQ:
是否有适用于学生的 Apple Developer Program?学生是否可享受任何折扣?
答:我们暂时未提供学生折扣或适用于学生的 Apple Developer Program。iOS Developer University Program 专为计划将 iOS 开发纳入课程大纲的高等教育机构而设计,这些教育机构必须得到国家承认并拥有学位授予权。
iOS Developer University Program 和 Apple Developer Enterprise Program 有何差别?
答:iOS Developer University Program 允许大学使用 iOS SDK 和其他 Apple 技术教授 iOS App 开发课程。通过 iOS Developer University Program,同一团队内的学生和教授可以通过电子邮件相互共享开发 App,也可以将其发布到私人网站以进行展示和评分。参与机构必须是符合资格、拥有学位授予权的高等教育机构。
Apple Developer Enterprise Program 适用于创建专有内部 iOS App 且仅用于内部部署的公司。组织注册此计划时需要使用 Dun & Bradstreet (D-U-N-S) Number。
谁应申请加入 iOS Developer University Program?
答:iOS Developer University Program 的注册请求应该由经授权的代表完成,该代表应该能够在法律上约束高等教育机构遵守计划条款和条件。
我们是否可以在由学生和教职工(已加入 iOS Developer University Program)共用的大学实验室计算机上安装 iOS SDK?
答:你可以在大学、大学员工或承包商拥有或控制的 Apple 品牌计算机上安装合理数量的 iOS SDK 副本,前提是此类使用仅限于同意 iOS Developer University Program 学生协议的大学学生以及其身份为大学授权开发者的大学员工或承包商。
学生应如何参加 iOS Developer University Program?
答:所有计划参与者必须首先注册为 Apple Developer。然后,学生可接受课程教员的邀请加入团队。在邀请接受过程中,学生需要查看并同意 iOS Developer University Program 学生协议,然后才能成为团队的有效成员。
是否可将学生列为 iOS Developer University Program 的团队管理员?
答:不能。学生只可以作为团队成员添加到 iOS Developer University Program。
Apple 是否会对我的高等教育机构执行身份验证?
答:是的。作为注册审查过程的一部分,Apple 将审查贵机构的身份信息。注册验证要求和处理时间不尽相同。
我是某高等教育机构的教授或员工,想要创建 App 并在内部发布给我的机构成员。我应该注册哪个计划?
答:要开发和生产供高等教育机构内部使用的 iOS App,我们建议你注册 Apple Developer Enterprise Program。
我是否可以同时注册 University Program 和 Enterprise Program?
答:可以。开发者可同时参加两个计划,但是必须使用唯一的 Apple ID 注册每一个计划。如果需要其他帮助或有任何其他问题,联系我们。
iOS Developer University Program 的团队最多可容纳多少人?
答:你可邀请合理数量的学生加入 iOS Developer University Program 团队。但是,团队每年最多可接受 200 台设备注册。
如果 App 由 iOS Developer University Program 中的学生开发,谁拥有其知识产权?
答:如果你希望在参与大学课程或项目的过程中开发 App,你应该就知识产权以及大学是否主张任何此类权利的问题咨询贵校。
我的高等教育机构确认我拥有知识产权,可以分发我以 iOS Developer University Program 学生参与者的身份开发的 App。怎样才能在 App Store 上分发我的 App?
答:你必须注册 Apple Developer Program 才能在 App Store 上分发 App。
是否有适用于学生的 Apple Developer Program?学生是否可享受任何折扣?
答:虽然没有专门针对学生的开发者计划,但每个人学习为 Apple 平台开发 App 都是免费的。只需一个 Apple ID,您就可以访问 Xcode、软件下载、文稿、示例代码、论坛和“反馈助理”,并可在设备上测试您的 App。此外,如果您报名了某教育机构提供的 iOS 开发课程,而该机构注册了 iOS Developer University Program,那么您可以访问适用于这些课程的会员资源并享受相应的会员权益。当你需要分发 App 时,则可以加入 Apple Developer Program。
总结:
申请入口 iOS Developer University Program,了解更多 官网页面。
一年 $99 的 Apple Developer Program 会员资格费用可以申请豁免:
Apple 会审核所有会费豁免请求。在会费豁免请求获批后,如果你在 App Store 上分发付费 App 或含有 App 内购买项目的 App,则你需要支付 99 美元的年度会费 (如果适用,则以当地货币计费)。
会费豁免不适用于:
更多详细信息,Apple Developer Program 会员资格费用豁免。
综上,苹果开发者账号:
账号类型 | 安装名额 | 使用有效期 | 优点 | 缺点 |
---|---|---|---|---|
Apple Developer Free Account(免费个人开发者) | 3 台 | 7天 | 1. 免费 | 1. 有效时间短 2. 安装麻烦 3. 不能上架 App Store |
Apple Developer Program(苹果开发者计划) | 100 台 | 365天(一年) | 1. 有效时间相对较长 2. 允许安装设备多 3. 可以上架 App Store | 1. 收费 $99 |
Apple Developer Enterprise Program(苹果开发者企业计划) | 无限 | 365天(一年) | 1. 有效时间相对较长 2. 允许安装设备无限 | 1. 收费 $299 2. 不能上架 App Store |
iOS Developer University Program(iOS 开发者大学计划) | 200名(台) | 365天(一年) | 1. 有效时间相对较长 2. 免费 | 1. 不能上架 App Store 2. 申请难 |
因为苹果 App Store 需要审核,并且审核的过程缓慢,当年一个新 App 可能经过一周才有审核结果,如果被拒一个月后才能正式上架,对于当年移动互联网时期的企业来说,分秒必争,可能等不了这么久,所以就出现了很多的新模式!
通过上面的表格,可以看出来,如果不上架 App Store 的情况下,希望分发安装 App ,可以有以下的方法:
开发者模式
从 iOS 16 开始,个人开发者帐号真机安装的测试 App 不能直接启动,会提示:“需要启动开发者模式”,此时需要开启 开发者模式 这个选项。开发者模式在 “设置 - 隐私与安全性”,划到最底下的安全性,可以看到 开发者模式
。开启开发者模式之后会重启手机,重启之后点击确认开启即可。
iOS 16 中引入的开发者模式,苹果表示用于保护用户在设备上无意中安装有害软件的问题,并减少仅由开发者功能暴露的攻击载体。
此举,可以让大部分普通用户不会去开启此功能,对于使用签名分发包体的方式,一方面教育用户启动开发者模式成本很高,另一方面苹果对于选择“开启”时,做了多重警告提示用户,包括重启设备、重启后二次确认。
企业账号
企业证书,目前苹果已经不在审批新的企业证书,石沉大海,并且账号重新审查越来越严,能续费的企业帐号越来越少,所以未来只会越来越少,直到消失。
那么,企业帐号本意是给企业内部分发 App 使用,那么如果企业帐号不能申请了?有什么代替方案?
答案是,自定 App 和非公开 App 方案,下文会介绍。
设备注册限制
从今年某个时间开始,苹果更新了 设备注册规则:
这个影响很明显,比如,后续新创建了一个苹果账号,那这个苹果账号添加设备的话,超过 10 个会一直要等 24 小时到 48 小时,不会实时添加了?那还分发个啥?
另外,如果过期账号,重新续费,也是这个逻辑,所以大家千万不要断供!
如果账号被苹果封号,关联的设备,在 30 天内,无法添加到其它开发者账号证书下。
从侧面验证,苹果对开发者账号、设备之间的联系性,实锤苹果是有检查!
所以这个规则,那些还在有效期内的帐号很值钱。但是一旦停止续费,那这个账号就废了!
通过这套组合拳(开发者模式 + 设备注册限制),已经破了个人开发者帐号分发的方案,因为688人民币一个帐号只能给 10 个设备安装 App,一个设备成本就是 68.8 元!
至此,通过宣传安全性的价值远大于启动开发者,启动开发者模式带来的不便,用户也不愿意开启。
非公开 App 分发:将不适合公开分发的 App 以非公开方式在 App Store 上发布,使其仅可通过直接链接被发现。非公开 App 不会出现在任何 App Store 类别、推荐、排行榜、搜索结果或其他列表中,但可以通过 Apple 商务管理和 Apple 校园教务管理进行访问。合作伙伴销售工具、员工资源或调查研究方面的 App 非常适合进行非公开分发。
将你的 App 分发至:
在你请求非公开 App 分发之前,你的 App 必须已在 App Store 中上架或已准备好进行最终分发且已提交至 App Review 团队。在提交内容的“审核注释”部分中添加注释,指明你的 App 将用于非公开分发。然后,提交非公开 App 分发请求。。
总结:
自定 App:与商务和教育机构客户接洽,根据他们所在组织的独特需求,为其设计和构建自定 App。通过 Apple 商务管理和 Apple 校园教务管理,你不但能以安全私密的方式向特定的合作伙伴、客户和特许经营者进行分发,而且还能向内部员工分发专属 App。
自定 App 是指你为特定组织打造的 App,包括组织内部使用的专属 App。你可以指定一个或多个组织,让其能够在 Apple 商务管理或 Apple 校园教务管理上看到和下载你的 App。然后,他们可以通过移动设备管理或兑换码来进行分发。
这里有 3 个概念:
自定 App 分发可以理解为就是替代“企业账号”的职能,唯一最大区别就是 App 要苹果审核!
总结:
注:Apple 商务管理或 Apple 校园教务管理,只在部分国家或地区可用,详见官网 可用情况。
所以,目前苹果分发和安装 App 的方案:
分发方式 | 费用 | 安装名额 | 有效时间 | 是否需要苹果审核 | 备注 |
---|---|---|---|---|---|
App Store | $99 | 无限 | 无限 | 是 | |
In-house(内部) | $299 | 无限 | 一年 | 否 | |
Ad Hoc(临时) | $99 | 100* | 一年 | 否 | 依赖 Apple Developer Program 账号,所以需要 $99 费用。 |
免费个人开发者 | 免费 | 3 | 7天 | 否 | |
TestFlight | $99 | 10000 | 90天 | 是 | 依赖 Apple Developer Program 账号,所以需要 $99 费用。 |
非公开 App 分发 | $99 | 无限 | 无限 | 是 | 依赖 Apple Developer Program 账号,所以需要 $99 费用。 |
自定 App 分发 | $99 | 无限 | 无限 | 是 | 依赖 Apple Developer Program 账号,所以需要 $99 费用。 |
*Ad Hoc 安装名额:
有限数量的用户可以直接在 Apple 设备上安装 Ad Hoc 分发的 App,以进行测试和内部分发:
综上,目前苹果无限安装的分发方式,除了仅存的小部分企业账号,新方式都是需要苹果审核,而旧的测试分发 Ad Hoc 因为设备注册的限制,成本过高而被淘汰,可以看出,苹果对分发安装 App 的管制是越来越严,那么 苹果会愿意开放侧载?
欧盟《数字市场法》(DMA,The Digital Markets Act)是为了规范大型互联网平台公司的运营:
显而易见,这就是欧盟为亚马逊、微软、苹果、Meta、Netflix、TikTok等,海外科技巨头量身定制的标准。对于其他科技企业而言,欧盟的《数字市场法》或许只能算“皮肉伤”,但对于苹果而言可能就会是伤筋动骨的切肤之痛了,其或将改变苹果整个软件生态的运行模式,进一步来说,几乎就相当于是要改变苹果软硬件结合的商业逻辑。
众所周知,苹果是这个星球在软硬件结合上做得最为出色的科技企业,左手是苹果旗下硬件设备出众的产品力,右手则是iOS、macOS、iPadOS所提供的安全、稳定、便捷的用户体验。但《数字市场法》则极有可能会打破这个二元结构,使得苹果旗下操作系统的封闭性难以为继。
根据《数字市场法案》中的要求,苹果方面将需要允许用户在iOS上安装第三方应用和应用商店,并允许第三方与其服务互操作,开发者还有权要求绕过苹果的支付系统。
引用来源:文章
综上,苹果一方面收缩了 iOS 分发 App 的广泛能力,另一方面在欧盟《数字市场法》压力下,苹果怎么选择?
不合规的后果是什么?
所以,我们看看苹果在 2023 年 11 月 2 日 公布的第四季度业绩 :
欧洲占比 24.6%,远远超过全球年营业额总额的 10%,如果你是苹果,你会怎么做?
根据欧盟《数字市场法》官网的日程表:
2024 年 3 月,就会有一个结论,到时候就知道啦~ 大家也可以在评论区说说自己的看法~
最后,如果觉得文章不错,掘金 2023 年度人气创作者打榜中,每天可投 2 票(截止 12 月 19 号):欢迎给我们投票~
欢迎大家评论区一起讨论交流~
我们是37手游移动客户端开发团队,致力于为游戏行业提供高质量的SDK开发服务。
欢迎关注我们,了解更多移动开发和游戏 SDK 技术动态~
技术问题/交流/进群等可以加官方微信 MobileTeam37
]]>注:如若转载,请注明来源。
本文首发于 苹果 App Store 支付弃用 API 接口兼容和解读 - 掘金,欢迎关注我们 @37手游移动客户端团队 。
作者:iHTCboy
摘要:本文介绍了苹果在 WWDC23 上宣布的对服务端的 2 个 API 弃用,包括verifyReceipt API和App Store Server Notifications V1。同时,本文还提供了相应的兼容迁移建议,包括从 verifyReceipt API 改为 Get Transaction Info API等。此外,本文还介绍了receiptData 旧收据伪造问题和苹果新推出的 App Store Server Library 工具包。
苹果在今年 WWDC23 宣布对服务端的2个 API Deprecated(已弃用),意思是API 后续不会有更新和维护,目前还可以用,但未来某天可能会完成不可调用。所以,现在开始需要做兼容和迁移的工作。
参考:What’s new in App Store server APIs - WWDC23 - Videos - Apple Developer
目前苹果有2套内购支付的 API:
通过这2个版本的支付 API,支付成功的凭证格式不同:
现在弃用的 verifyReceipt API,就是通过 receipt-data 支付凭证内容校验的接口。
提示: 虽然苹果宣布弃用 verifyReceipt API,但 StoreKit Original API 并没有弃用,并且在 visionOS 中还支持:
所以:
笔者预计未来2~3年内,仍然有大部的 App 使用 StoreKit Original API,导致苹果不会删除相关的 API 和后端验证 verifyReceipt API。但建议开发者,现在开始考虑迁移到新的 API。
苹果给的迁移和兼容的建议:
参考:Meet the App Store Server Library - WWDC23 - Videos - Apple Developer
苹果建议开发者,从 verifyReceipt API 改为 Get Transaction History | Apple Developer Documentation API。
有关 Get Transaction History API,可以参考我们之前的文章:WWDC21 - App Store Server API 实践总结 - 掘金
API 查询到交易历史记录返回结果只支持以下情况:
所以,如果使用这个 API 校验交易订单号(transactionId),可能需要注意,如果客户端已经调用苹果 finish() | Apple Developer Documentation 或finishTransaction(_:) | Apple Developer Documentation API 后,查询 Get Transaction History API 会返回 404 Not Found。
今年苹果 WWDC23 新提供的 API,可以查询某个 transactionId 收据信息,包体finish的消耗型商品。
参考:What’s new in App Store server APIs - WWDC23 - Videos - Apple Developer
App Store Server Notifications V1 和 V2 通知,是 App Store 服务器主动通知开发者服务器的 API。比如退款通知、订阅商品续费成功通知等。
目前苹果已经弃用 V1 版本的 API:
参考:App Store Server Notifications V1 | Apple Developer Documentation
V1 和 V2 的主要区别:
V2 支持更多的通知类型:
V2 重试更多:
V2 JWS 格式中的 payload 解析:
关于 App Store Server Notifications V2 更新内容,可以参考我们之前的文章:
相关官方文档:
对于 StoreKit Original API 获取的 receiptData 凭证,苹果在客户端有 2 个 API :
格式区别: 这 2 个 API 获取的 receiptData 凭证,经过苹果 verifyReceipt API 解析后的格式是不同的。
问题: 目前发现, iOS 7 之前的旧凭证 API,黑产能伪造票据中的 Bundle ID !
目前不能伪造的字段:
建议:
提示:苹果对旧凭证收据更新了 SHA-256 加密算法:
即将推出的 AppStore 收据签名媒介证书相关更新 - 最新动态 - Apple Developer
针对上述的 App Store 校验,苹果现在推出官方的服务器工具包(库),减少开发者接入难度和成本,同时也避免校验漏洞等问题。
参考:Meet the App Store Server Library - WWDC23 - Videos - Apple Developer
本文概述了苹果 App Store 相关 API 和开发者链的变化。首先讨论了 verifyReceipt API 的弃用和开发者迁移到较新 API 的必要性。接着,介绍了 App Store 服务器通知 V1 的弃用以及 V1 和 V2 通知之间的区别。另一个重要的话题是旧的 receiptData 格式存在伪造凭证的风险。最后,文章介绍了 App Store 服务器库,这是一组旨在简化与苹果 API 集成的工具。这个库提供了 Java、Swift、Python 和 Node.js 版本。
最后,开发者应该马上注意这些变化,并采取措施及时更新他们的代码。这些变化对开发人员的工作有重要影响,了解这些变化并及时更新代码可以帮助开发人员更好地使用苹果 App Store API 和工具,提高开发效率和应用质量,同时也避免旧 API 存在漏洞导致出现安全风险的问题。
如有问题,欢迎大家评论区一起交流~
]]>我们是37手游移动客户端开发团队,致力于为游戏行业提供高质量的SDK开发服务。
欢迎关注我们,了解更多移动开发和游戏 SDK 技术动态~
技术问题/交流/进群等可以加官方微信 MobileTeam37
本文是《WWDC23 内参》参与创作者,首发于 WWDC23 10117 - App Store Connect 的新特性 - 小专栏。
本文基于 Session 10117 、Session 10012 和 Session 10015 梳理。
摘要:本文介绍了 App Store Connect 的新特性,包括隐私保护、新增的数据类型、按地区预购、产品页优化和通过 API 实现自动化等方面。其中,仅限内部测试人员访问的 TestFlight 测试更早安全可控;按地区预购可以为现有 App 拓展新的市场;通过 API 实现自动化流程以节省时间。最后建议开发者尽早尝试新功能,优化产品页面,激发用户的兴趣,获取更多用户。
作者:
iHTCboy,目前就职于三七互娱集团旗下 37 手游,从事多年游戏 SDK 开发,对 IAP 和 SDK 架构有丰富的实践经验。
审核:
SeaHub,目前任职于腾讯 TEG 计费平台部,负责搭建服务于腾讯系业务的支付系统,主导国内 IAP 前后端相关内容,对 IAP 整体设计有一定的经验。
黄骋志:老司机技术轮值主编,目前就职于字节跳动,参与西瓜视频质量与稳定性工作。对 OOM/Watchdog 较为了解并长期投入。
App Store Connect 是苹果提供给开发者用来管理 App 信息、提交审核、查看 App 数据等功能的平台。本次 WDCC23 中苹果对 App Store Connect & StoreKit 做了不少的改进和优化:
无论您是一个独立开发者还是一家大公司,当我们开发 App 时,我们都需要考虑是否包含 IAP(In-App Purchase,应用内购买)功能以及如何设定价格等。今年新推出的功能可以快速帮助我们在 App Store 上推广和销售 App,并快速实现 App 获利。
我们都知道,StoreKit 的功能繁多,支付流程和逻辑复杂,自己从零开始搭建一个 IAP 支付流程非常不容易。现在,苹果推出 StoreKit for SwiftUI 新功能,它可以让我们快速轻松地在应用程序中提供应用内购买和订阅功能。我们只需在 App Store Connect 中创建商品,然后在 Xcode 中添加以下几行代码,就可以在 App 中创建购买商品的视图。
如上图,通过 SubscriptionStoreView API 就能创建一个最简单的商品订阅组的购买视图。当然,苹果提供一些 API 实现自定义背景、按钮和样式等元素,并且这个商品信息会自动显示本地化的语言,以实现与我们 App 界面设计风格的无缝衔接,如下图就是一个自定义风格的代码示例:
借助 StoreKit 提供的全新 SwiftUI 视图,打造出色的 App 内购买项目和订阅商品展示体验变得比以往更加容易。利用三种不同的 StoreKit 视图在各种 Apple 平台上展示你的产品:StoreView、ProductView 和 SubscriptionStoreView ,这个 API 可以比以往更快地将商品展示视图搭建好并投入使用。只需使用短短一行代码,即可向用户清楚地显示各级服务的描述、价格和时限。优点总结:
App Store 推广 让用户能直接在 App Store 上浏览 App 内购买项目,并能在下载 App 之前就开始购买这些项目,从而帮助我们提升 App 内容的曝光度。我们可以在自己的 App 产品页上推广最多 20 个 App 内购买项目,其中可包括订阅服务。
使用 App 内购买项目推广功能之前,我们需要在 App Store Connect 为准备推广的 App 内购买项目上传宣传图标。在之前的 OS 系统中,开发者是无法直接读取 App Store Connect 配置的推广图标的。
现在,利用 ProductView API 就可以创建一个商品视图,通过 prefersPromotionalIcon
字段设置为 true
就可以使用推广图标。
如果想要深入了解 StoreKit for SwiftUI 的内容,推荐参考以下内容:
如果我们的 App 面向全球市场,那么我们需要考虑如何设定价格以及如何定价。今年 5 月 9 号,苹果升级了 App Store 定价功能,使管理应用、应用内购买和订阅的价格变得更加容易。
定价更新
如果想要深入了解 App Store 定价功能更新的内容,推荐参考以下内容:
TestFlight 是苹果旗下的 App 测试平台,能帮助开发者邀请用户对 App 进行测试,方便开发者更好地改进和完善 App。
去年 TestFlight 支持 macOS app 测试,今年苹果推出 visionOS,所以,现在 TestFlight 可以轻松地在 iOS、watchOS、tvOS、macOS 和最新的 visionOS 上测试预发布版本的 App。TestFlight 针对所有现有的操作系统,提供了安装 beta 版本 App 统一的用户体验。
在 visionOS 中的 TestFlight app,如反馈问题的交互操作可能因平台特性而不同,其它功能与其它平台大致相同。
首先,在 App Store Connect 创建 visionOS app 有 2 种形式,一种是以原生 Apple Vision 原生平台构建的 App,另一种是以 Designed for iPad / iPhone app 形式兼容的 visionOS App。
以兼容这种方式提供的 App,不需要修改任何代码或提交新版本,在 App Store Connect 后台的 “价格与销售范围” 页面,有一个 iPhone and iPad Apps on xrOS
选项,勾选提供此 App 即可让 visionOS 设备上的用户尽快享受我们的 App。当然,可以让测试人员在 visionOS 中帮助我们测试 iOS app 兼容性,如上图,在 TestFlight app 找到测试的 App,页面顶部有一个 xrOS iOS
切换的选项卡进行切换。如果安装的是兼容的 iPad/iPhone app 在 visionOS 上的 App,会被放到一个名叫 Compatible Apps
的文件夹中,以表示这些 app 是兼容模式。
与其它平台一样,所有通过 TestFlight app 安装在 visionOS 的 App,默认在 App 名称的左边显示一个黄色圆点,安装的 beta 版本 App,可以直接从 TestFlight 或 Home Screen
(主屏幕)中启动。
最后,测试人员在 visionOS 上使用 App 后,可能想反馈一些体验和改进建议等,首先,visionOS 上截图的快捷键是同时按住 Digital Crown
(数字表冠)和 top buttons
(顶部按钮),然后打开 TestFlight app 找到 Send Feedback
按钮,可以输入描述问题的文本,然后可以添加附件,可以选择刚才的截图,对截图进行裁切或标注文字等,最后点击提交就完成了反馈。另外,如果 App 在运行过程中崩溃,visionOS 会显示 Alert 弹窗,标题是 "xxx" Crashed
,测试人员可以选择拒绝或分享,如果分享则测试人员可以描述导致崩溃的步骤,然后和捕获的崩溃日志一起提交。
如果想要深入了解 TestFlight for visionOS 的内容,推荐参考以下内容:
借助对测试员管理功能所做的更新,充分利用 TestFlight 中的 Beta 版测试流程,这些更新有助于你更好地了解测试员并获取有价值的新详情。
可获取测试人员的设备型号和操作系统版本
查看最近安装的设备类型和测试员在测试 App 时使用的 OS。
测试人员批量分组管理
根据测试员的参与程度 (由 App 使用次数,App 崩溃次数和反馈量指示),对测试员进行过滤和排序。并且可以同时对多名测试员执行重要操作,如重新发送邀请、添加到组或完全删除测试人员等。当然 App Store Connect API 也支持这些功能。
仅限内部测试人员访问的 Beta 版本
以往,开发者构建 App 时,同一个版本包体可以用于 TestFlight 测试和 App Store 审核,但是这样,可能会导致管理测试人员和版本时容易出错。比如,你构建了一个临时的分发版本,我们可能不想将其分发到内部团队之外。所以,Xcode 15 苹果提供了 TestFlight Internal Only
选项,它将确保这个版本无法发布用于外部 TestFlight,也无法提交到 App Store 审核。
在 App Store Connect 中,这些内部测试版本将被清晰标记为 Internal
,以便我们可以轻松查看哪些版本可以分发到哪里。
最后,可以利用 Xcode Cloud 在构建时上传 TestFlight 测试内容信息,详细参考文档:Including notes for testers with a beta release of your app 。
当然,也可以在 App Store Connect 后台填写,或者使用 App Store Connect API 提交测试内容。
如果想要深入了解 Xcode 15 for TestFlight 的内容,推荐参考以下内容:
创建家庭共享的沙盒测试
借助“家人共享”,用户可与另外最多五名家庭成员共享 iCloud+、Apple Music、Apple TV+、Apple Fitness+、Apple News+ 和 Apple Arcade 等 Apple 服务的访问权限。用户的群组还可以共享 iTunes、Apple Books 和 App Store 购买项目。你们甚至可以协助定位彼此丢失的设备。
借助“家人共享”,主账号可以共享 Apple 订阅项目。现在为了使开发者能够在发布之前测试此功能,苹果添加了将沙箱测试帐户合并到家庭组中的功能。开发者可以在 App Store Connect 中配置这些帐户,一个家庭分组最多可以有六个测试帐户。
设备上的沙盒账号
苹果在 iOS 17 上添加了以下沙盒设备增强功能:
如果想要深入了解 StoreKit testing in sandbox 的内容,推荐参考以下内容:
接着,我们介绍一些构建 App Store 形象的方法。App Store 产品页面是我们向用户介绍 App 功能的地方。App Store Connect 可以帮助我们配置产品页面、激发用户兴趣、并获取用户等。
App Store 可以帮助用户在下载 App 之前更好地了解 App 的隐私保护做法。在每个 App 的产品页上,用户可以了解 App 可能收集的一些数据类型,知道相关信息是否用于跟踪用户,以及是否关联到用户的身份信息或设备,以便用户在下载我们的 App 时更加清楚和信任,并做出明智的决定。
随着 visionOS 的推出,苹果新增了一些新的数据类型。
Environment Scanning
(环境扫描)。Hands
(手部)。Head
(头部)。例如,有一个 App 是教用户如何弹钢琴并收集其手部运动的数据以指导他们改进,则应该选择 “Hands” 数据类型进行数据收集。这些新数据类型与 visionOS 应用程序特别相关,但也可以应用于其他平台。(笔者注:如 iOS app 通过 VisionKit 识别用户手势。)
这些新数据类型将展示在 visionOS App Store 以及上架发布的所有其他平台。
以预购的形式提供 App 是在发布之前提高知名度并提升用户期待值的绝佳方式。
今年,开发者可以按地区以预购的形式提供 App。这功能带来了新的灵活性,让你能够在有限的地区内试发布新的 App,同时在其他地区以预购的形式提供 App。你甚至可以为每个地区设置不同的发布日期。如果你想要为现有 App 拓展新的市场,可以在这些新的地区以预购的形式发布 App。
需要注意,只有过审且未发布的 App 才能使用按地区预购的功能。所以,如果已经上架过某些国家或全球地区的 App,是不可以重新按地区预购。按地区预购,首先开发者在某个地区发布上线,苹果称为 soft launch
(软启动),然后其它未上架的国家地区,开发者可以选择提供按地区预购。
举个例子,假设我们有一个新的过审未发布的 App,打算先在加拿大地区上线,现在我们可以先单独设置为加拿大地区开启预购,能设置的最长发布日期是当前算起的 180 天内。假设我们 App 最终 2023 年 9 月 1 号发布上线加拿大地区的 App Store,现在希望在美国地区上线,则现在可以设置最长发布日期是从 2023 年 9 月 1 号算起的 365 天内。
这里有一些细节苹果没有谈到,比如后续再上线第 3 个新地区时,发布日期是否还能往后 365 天?还是超过首次上架后的 365 天后,应用不能在开启预购?还有就是将预购从 App Store 中移除后,若发布日期已过,以前我们无法再将 App 以预购形式发布,而现在的按地区预购还可以重新开启预购吗?目前在官方 文档 还没有更新,后续大家可以再关注一下具体细则。
最后,当我们以预购形式发布后,我们在宣传我们的 App 时,我们可以在网站和营销材料中加入 App Store 徽章,简单明确地指引用户获取你的 App。获取本地化的 App Store 徽章可参考 营销资源和识别标志指南。
通过产品页优化,开发者可以测试 App Store 产品页的不同元素,了解哪些元素带来的用户参与度最高。
有了按地区预购的功能后,App 不同地区的版本管理可能变得复杂,同时产品页优化,可能针对不同国家或地区进行测试,但如果要对已经上架的地区更新版本的话,会导致正在测试的版本停止。现在,你可以发布新的 App 版本而不中断正在运行的测试,这让你可以更加灵活地制定 App 发布计划。
所以,我们能够查看和监控当前正在测试的产品页,同时根据需要更新 App。但请记住,产品页优化的目的是将测试组与对照组进行比较,因此新版本产品页面的任何更改都可能会影响正在运行的测试的结果。
小结
如果想要深入了解 visionOS、privacy 和按地区预购的内容,推荐参考以下内容:
App Store Connect API 提供了用于自定义工作流程,可以实现与开发者内部系统保持同步,最终通过自动化流程以节省时间。
今年,苹果推出了应用内购买和订阅、用户评论和回复以及管理沙箱测试人员的功能的 API。还有很多 API 调整细节,如 List All Price Points for an In-App Purchase 和 List All Price Points for a Subscription 请求最大数量从 200 提升到 8000。更多更新内容,参考文档:App Store Connect API 2.4 release notes 。
Game Center 是 Apple 的社交游戏网络,旨在帮助玩家与朋友一起体验游戏的乐趣。
使用增强的 Game Center API,更轻松地设置和管理成就以及排行榜。
生成 App Store Connect API 密钥,以前只支持创建以下角色的权限:
具体角色的权限,可参考文档:Apple Developer Program 职能 。
API 的权限有点大,现在增加 营销
和 客户支持
权限。比如,客户支持就是只能查看评分与评论和回复顾客评论,权限颗粒度更细,更加安全。另外,还可以创建基于用户的密钥,也就是无论您担任什么角色,这个 API 密钥具有与您相同角色的权限,而不是固定不变的权限。
苹果鼓励我们尝试新功能,多学习和多使用这些新的特性,并可以与苹果分享自己的想法。如果遇到问题,可以通过 Apple 开发者网站 联系我们,网站上可通过电话或电子邮件获取无限支持。苹果提供了 9 种语言服务支持,并且是全天候 24 小时随时联系。
另外,如有以下情况:遇到与 Apple 软件或硬件相关的问题、想要提出 SDK 功能请求、发现 Apple 提供的 API 存在代码级错误和问题,或者注意到开发者文档中有错误或缺漏。开发者使用 “反馈助理” App 提交反馈。
注:启动和下载 “反馈助理” App 的方法:
iPhone 和 iPad。在 Beta 版 iOS 和 iPadOS 中,主屏幕上会默认显示该 App。在公开发行版 iOS 和 iPadOS 中,该 App 可以通过安装 Beta 版描述文件来启用;或是通过 applefeedback:// URL 方案来启动。
Mac。在所有版本的 macOS 上,都可以在 CoreServices 文件夹中找到该 App,并可以通过 applefeedback:// URL 方案或在“聚焦”中搜索“反馈助理”来启动它。
App Store Connect 提供了苹果全平台的功能,包含 iOS、iPadOS、watchOS、tvOS、macOS、visionOS 的管理,导致系统相当的复杂,近年来苹果希望平台功能趋于统一,降低开发者 App 迭代开发和管理维护的成本,如今年推出 StoreKit for SwiftUI。当然,目前 App Store Connect 依然还有很多问题,如上传构建的 App,目前只能通过 Xcode 或者 Transporter app,大家更加期待通过 App Store Connect API 能实现等。
最后,截止本文发表,上述介绍的很多功能还没有更新上线,苹果开发者网站显示今年晚些时候推出,所以最终的效果和规则以官方更新为准。随着功能不断增加,苹果鼓励开发者尽早尝试新功能,优化产品页面,激发用户的兴趣,以吸引和获取更多用户!
]]>本文首发于 iOS 防 dump 可行性调研报告 - 掘金,欢迎关注我们 @37手游移动客户端团队 。
作者:ChatGPT(GPT-4) & iHTCboy
摘要:本文介绍了如何防止iOS App 被dump,包括代码混淆、加密、完整性检查等多层防御策略,以及服务器端验证、动态加载、API安全性和多因素认证等方案。此外,监控与告警、定期安全审计和安全培训等后置方案也可以提高 App 的安全性。最后,还介绍了禁止越狱设备的实施方案,以及 DeviceCheck 和 App Attest API 等新技术方案。
在 iOS 平台上,保护 App 的源代码安全是开发者的一项重要任务。由于 App 可能包含敏感信息和重要算法,防止源代码被非法获取和篡改显得尤为重要。了解防止 App 的源代码被非法反编译或者 dump,有必要采取一定的安全策略。本文将对 iOS SDK 的防 Dump 技术进行调研,并提出一些建议和可行的方案。
本报告将从四个方面对 iOS SDK 防 dump 的技术方案进行探讨:
需要防,首先需要先了解有那些攻击技术。所以我们先介绍常见 iOS dump 技术。
在 iOS 平台上,攻击者可能采用多种技术手段对 App 进行破解、分析和攻击。以下是一些常见的 iOS dump 技术方案:
1. 反编译: 反编译是将二进制文件转换回源代码的过程。对于 iOS App ,攻击者可以使用如 Hopper, IDA Pro, Ghidra 等反编译工具对 App 进行静态分析,从而获取源代码、资源文件等敏感信息。
2. 动态分析: 动态分析是在 App 运行时进行的分析过程。攻击者可以利用工具,如 Frida、Cycript、GDB 等,对运行中的 App 进行实时分析、修改和调试,从而突破安全防护措施。
3. 反调试: 反调试是防止调试器附加到 App 的过程。攻击者可能会使用反调试技术,如 ptrace、sysctl 等,来检测和绕过 App 的调试防护。
4. 内存 dump: 内存 dump 是从运行中的 App 中提取内存数据的过程。攻击者可以利用如 Clutch、Fridump 等工具从 App 的内存中提取敏感数据和关键信息。
5. 二进制破解: 二进制破解是修改 App 的二进制文件以突破安全限制的过程。攻击者可以使用工具,如 Hex Fiend、MachOView 等,直接修改 App 的二进制文件以实现特定目的。
6. 代码注入: 代码注入是将恶意代码插入到 App 中以实现特定功能的过程。攻击者可以使用如 Theos、MobileSubstrate 等技术将恶意代码注入到 App 中,实现代码执行、功能修改等目的。
7. 交叉编译: 攻击者可能会使用如 LLVM、clang 等交叉编译器,将 App 编译为其他平台的可执行文件,以便在其他平台上进行分析和调试。
8. 虚拟化: 攻击者可以使用虚拟化技术,如 QEMU、Corellium 等,在虚拟环境中运行 iOS App ,实现对 App 的分析和调试,避免被实际设备的安全措施检测到。
下面,针对几个不太熟悉的技术进行介绍。
Frida、Cycript 和 GDB 是常见的动态分析工具,攻击者可以使用这些工具在运行时对 iOS App 进行实时分析、修改和调试。
接下来我们详细介绍这三种工具:
Frida 是一个跨平台的动态代码插桩框架,支持多种操作系统,包括 iOS。它允许开发者和安全研究员在运行时注入自己的代码片段,以便对目标程序进行实时分析和修改。攻击者可以使用 Frida 对 iOS App 进行以下操作:
Frida 提供了丰富的 API 和脚本语言支持,如 Python、JavaScript 和 Swift,使得攻击者可以轻松地编写自定义脚本,以实现特定目的。
Cycript 是一个用于 iOS 平台的动态分析工具,允许在运行时探查和修改 Objective-C 和 JavaScript App 。攻击者可以使用 Cycript 进行以下操作:
Cycript 的交互式命令行界面使得攻击者可以轻松地实时探查和修改目标 App 。
GDB(GNU Debugger)是一个功能强大的源代码级调试器,支持多种平台,包括 iOS。攻击者可以使用 GDB 对 iOS App 进行以下操作:
GDB 提供了丰富的命令和扩展接口,使得攻击者可以对目标 App 进行深入的分析和调试。
ptrace 和 sysctl 是两种与调试和进程管理相关的系统调用。它们在底层操作系统中实现,并为用户级程序提供了一定程度的控制和信息。
ptrace(process trace)是一种 UNIX 和类 UNIX 系统中的进程跟踪和调试功能。它允许一个进程观察和控制另一个进程的执行。通过 ptrace,调试器可以捕获目标进程的系统调用、信号处理和其他事件,以及检查和修改目标进程的内存和寄存器。
原理:当调试器使用 ptrace 附加到目标进程时,操作系统会将调试器的 ID 与目标进程关联。调试器可以使用 ptrace 请求来控制和监控目标进程。当目标进程遇到相关事件(如系统调用、信号处理等)时,操作系统会将事件通知给调试器,调试器可以根据需要进行相应操作。
sysctl 是一种用于获取和设置内核参数的接口。它用于访问内核中的数据结构,以获取和修改系统的运行时配置。sysctl 主要用于系统管理和监控任务,但在某些情况下,它也可用于检测和绕过 App 的调试防护。
原理:sysctl 通过内核和用户空间之间的通信接口实现。用户空间的程序可以通过 sysctl 系统调用或特定的虚拟文件系统(如 /proc 和 /sys)访问内核参数。在 iOS 中,例如开发者可以使用 sysctl 函数查询进程信息,如进程列表、内存使用情况等。此外,通过检查 sysctl 返回的数据,攻击者可能会检测到调试器的存在,从而采取相应措施绕过调试防护。
dlopen 和 dlsym 是动态链接库加载和符号解析的函数。它们允许运行时动态加载共享库并解析库中的符号(如函数和变量)。这些功能可以用于实现插件系统、动态代码执行和运行时代码替换等。
mmap 和 munmap 是用于内存映射管理的系统调用。它们允许进程将文件或其他资源映射到虚拟内存空间,以便直接访问和操作。mmap 可用于实现内存共享、文件 I/O 优化和动态代码加载等。
getpid 和 getppid 是用于获取进程 ID 和父进程 ID 的系统调用。它们可以用于进程管理和监控,以及分析程序的运行环境和上下文。
fork 和 exec 是用于创建新进程并执行程序的系统调用。fork 用于创建当前进程的副本,而 exec 用于替换当前进程的映像并执行新程序。这些功能可用于实现多任务、并发执行和进程间通信等。
kqueue(BSD 系统)和 epoll(Linux 系统)是用于异步 I/O 事件通知的高效接口。它们允许进程在没有阻塞的情况下监控文件描述符、信号和其他事件。这些功能可用于实现高性能的网络服务器、事件驱动程序和异步任务处理等。
断点允许调试器在特定位置暂停程序的执行。当程序达到断点时,调试器会中断程序执行,允许开发者或攻击者检查当前状态(例如变量值和调用堆栈),并逐步执行代码。断点通常通过替换目标位置的原始指令(例如使用 INT 3 指令)来设置,当处理器执行该指令时,将触发软件中断,将控制权交还给调试器。
单步执行允许调试器逐行或逐指令地执行程序,这有助于开发者或攻击者理解程序的执行过程。单步执行的原理是在每一步都设置临时断点,并在执行完一条指令后将控制权返回给调试器。
函数跟踪允许调试器记录程序中的函数调用顺序。这对于分析程序的执行流程和理解函数之间的依赖关系非常有用。函数跟踪可以通过在函数入口处设置断点并捕获调用堆栈信息来实现。
调试器可以监控程序的内存访问,以便查找和分析程序中的数据存储和传输。内存读写监控的原理是将目标内存页面设置为不可访问,当程序访问这些页面时,触发硬件或软件异常。调试器捕获此异常,并分析引起异常的访问,然后将内存页面的访问权限恢复,以便程序继续执行。
调试器可以将程序的机器代码反汇编为汇编语言表示,以便更好地理解程序的执行过程。通过对反汇编代码进行分析,开发者或攻击者可以识别感兴趣的代码区域,例如加密算法、密钥存储和验证逻辑等。
动态插桩允许在程序运行时插入额外的代码,以便捕获和修改程序的行为。这可以通过修改程序的指令指针或使用特定的插桩框架(如 Frida)来实现。动态插桩可以用于实时分析和修改程序的数据和执行流程。
调试器可以使用符号表(如果可用)将程序的内部地址解析为更具可读性的函数名和变量名。这有助于开发者或攻击者更容易地理解程序的结构和功能。符号解析的原理是通过查找程序的符号表(如果可用)或使用其他可用的调试信息,将程序的内部地址与源代码中的变量名、函数名等相关联。这有助于开发者或攻击者更容易地理解程序的结构和功能。在 iOS 开发中,调试器如 LLDB 可用于解析符号信息。
在 iOS 中,这些调试技术通常结合专用的调试器和工具使用。以下是一些在 iOS 中应用这些调试技术的方法和工具:
1. 断点: 在 Xcode 中,开发者可以方便地设置断点。Xcode 集成了一个强大的调试器(LLDB),可以在 Objective-C 和 Swift 代码中设置和管理断点。
2. 单步执行: 在 Xcode 的 LLDB 调试器中,开发者可以逐行或逐指令地执行代码。Xcode 提供了“Step Over”、“Step Into”和“Step Out”按钮,以便在调试过程中控制代码的执行。
3. 函数跟踪: 在 LLDB 调试器中,可以使用“bt”(backtrace)命令获取当前线程的调用堆栈。这有助于分析函数调用顺序以及识别潜在问题。
4. 内存读写监控: LLDB 支持内存读写监控。可以使用“watchpoint set variable”命令为特定内存地址设置监视点。当该地址被访问或修改时,LLDB 会中断程序执行并通知开发者。
5. 反汇编和代码分析: 在 LLDB 中,可以使用“disassemble”命令查看反汇编的汇编代码。另外,还可以使用第三方工具,如 Hopper Disassembler 和 IDA Pro,进行更深入的代码分析。
6. 动态插桩: 在 iOS 中,可以使用 Frida、Cycript 等工具进行动态插桩。这些工具允许开发者和安全研究员在运行时注入自定义脚本,以实时分析和修改 App 的行为。
7. 符号解析: 在 LLDB 调试器中,可以使用“image lookup”命令查找符号信息。这有助于将内部地址解析为更具可读性的函数名和变量名。
能防 dump 的技术方案,意思是做了就可以 “防止” dump,并不是真能防止 dump 操作。
1. 代码混淆:通过对源代码进行混淆处理,使得源代码难以阅读和理解,增加攻击者分析代码的难度。
2. 加密技术:对关键数据和代码进行加密处理,确保在被 dump 时,攻击者无法直接获取敏感信息。
3. 完整性检测:对 App 代码进行完整性检测,如发现代码被篡改,则触发相应的安全策略。
4. 运行环境检测:检测当前 App 运行环境是否安全,如发现越狱设备或调试环境,则触发相应的安全策略。
对源代码进行混淆处理,包括变量名、函数名、类名等的替换,以及控制流混淆等。这使得源代码难以阅读和理解,增加攻击者分析代码的难度。
一个简单的混淆示例:
1 | class HelloWorld { |
混淆后的代码:
1 | class A1B2C3 { |
对关键数据和代码进行加密处理,确保在被 dump 时,攻击者无法直接获取敏感信息。
一个使用 AES 加密的示例:
1 | import CryptoSwift |
对 App 代码进行完整性检测,如发现代码被篡改,则触发相应的安全策略。
一个简单的完整性检测示例:
1 | func verifyIntegrity() -> Bool { |
检测当前 App 运行环境是否安全,如发现越狱设备或调试环境,则触发相应的安全策略。
一个简单的运行环境检测示例:
1 | // 越狱设备 |
ptrace 是一种用于跟踪和操纵其他进程的系统调用。攻击者可以使用 ptrace 附加到目标进程,以便在运行时读写内存、设置断点和单步执行等。为了防止这种调试行为,开发者可以在 App 中使用 ptrace,使其在检测到调试器时拒绝附加。这种方法通常称为 “anti-ptrace
“。
一个简单的反 ptrace 示例:
1 | #include <stdio.h> |
ptrace(PTRACE_TRACEME, 0, NULL, NULL) 是一个使用 ptrace 系统调用的特殊用法。在这种情况下,它的目的是让当前进程( App )被其父进程(调试器)跟踪。下面是各个参数的含义:
PTRACE_TRACEME
:这是 ptrace 系统调用的一个请求类型。PTRACE_TRACEME 用于告诉内核,让当前进程的父进程跟踪当前进程。换句话说,它允许调试器控制和监视 App 的执行。0
:这是 ptrace 调用的第二个参数,表示要跟踪的目标进程的 ID。在 PTRACE_TRACEME 的情况下,我们设置为 0,表示当前进程( App )是要跟踪的目标。NULL
:这是 ptrace 调用的第三个参数,通常表示要读/写的地址或数据。在 PTRACE_TRACEME 的情况下,此参数不使用,因此设置为 NULL。NULL
:这是 ptrace 调用的第四个参数,通常用于传递附加信息或数据。在 PTRACE_TRACEME 的情况下,此参数不使用,因此设置为 NULL。在这个例子中,我们使用 PTRACE_TRACEME 请求调用 ptrace。正常情况下,只有父进程(即调试器)才能对子进程(即 App )发出 PTRACE_TRACEME 请求。但是,如果 App 本身发出 PTRACE_TRACEME 请求并成功,那么意味着没有调试器附加到 App 。如果 PTRACE_TRACEME 请求失败(返回 -1),则说明已有调试器附加到 App 。这时,我们可以采取相应措施,如输出警告信息、终止进程或执行其他安全策略。
需要注意的是,虽然反 ptrace 可以提高 App 的安全性,但它并不是绝对可靠的。经验丰富的攻击者可能会使用更复杂的技术来绕过反 ptrace 保护,例如通过修改 ptrace 函数的实现或使用其他调试接口。
绕过反 ptrace 保护:
修改 ptrace 函数的实现:攻击者可以使用动态链接器(如 LD_PRELOAD)将自定义版本的 ptrace 函数加载到 App 中。自定义版本的 ptrace 函数可以在检测到 PTRACE_TRACEME 请求时不执行任何操作,从而绕过反 ptrace 保护。以下是一个简单的示例:
1 | #include <sys/ptrace.h> |
要使用此自定义 ptrace 函数,攻击者可以将其编译为共享库(如 libcustom_ptrace.so),然后在启动 App 时设置 LD_PRELOAD 环境变量,以便在 App 中使用自定义版本的 ptrace 函数。
1 | $ gcc -shared -fPIC custom_ptrace.c -o libcustom_ptrace.so |
因此,为了确保 App 的安全,最好采用多层防御策略,结合其他安全措施,如代码混淆、加密和完整性检查等。
sysctl 是一个用于查询和修改内核参数的系统调用。它提供了许多用于获取进程相关信息的选项,其中一些选项可以用来检测调试状态。
在 macOS 和 iOS 上,可以使用 sysctl 系统调用检查进程标志(例如 P_TRACED),以确定目标进程是否正在被调试。
以下是一个简单的示例:
1 | #include <stdio.h> |
在提供的代码示例中,bool is_being_debugged() 函数用于检测当前进程是否正在被调试。这个函数没有参数。
以下是对这个函数中涉及的每个变量和步骤的详细解释:
int mib[4] = {CTL_KERN, KERN_PROC, KERN_PROC_PID, getpid()};:mib 是一个整数数组,包含 4 个元素,用于 sysctl 系统调用。这些元素分别表示:
a. CTL_KERN:表示我们要查询的是内核相关的参数。
b. KERN_PROC:表示我们要查询的是进程相关的参数。
c. KERN_PROC_PID:表示我们要根据进程 ID 查询特定进程的信息。
d. getpid():这是一个系统调用,用于获取当前进程的 ID。这意味着我们将查询当前进程的信息。
**struct kinfo_proc info;**:声明一个 kinfo_proc 结构体变量 info,用于存储 sysctl 返回的进程信息。
**size_t info_size = sizeof(info);**:声明一个 size_t 类型的变量 info_size,用于存储 info 结构体的大小。sysctl 函数需要这个信息来填充 info 结构体。
**if (sysctl(mib, 4, &info, &info_size, NULL, 0) == -1) {…}**:调用 sysctl 函数来获取进程信息。sysctl 函数的参数如下:
a. mib:表示查询的参数数组。
b. 4:表示 mib 数组的长度。
c. &info:指向 kinfo_proc 结构体的指针,sysctl 将把查询结果存储到这个结构体中。
d. &info_size:指向 info_size 变量的指针,告诉 sysctl 函数 info 结构体的大小。sysctl 函数还会通过这个指针返回实际填充的数据大小。
e. NULL, 0:这两个参数表示我们不需要设置任何内核参数,只需要获取进程信息。
如果 sysctl 函数返回 -1,表示发生了错误。在这种情况下,函数通过 perror(“sysctl”) 输出错误信息,并返回 false。
return (info.kp_proc.p_flag & P_TRACED) != 0;:检查进程标志中的 P_TRACED 标志。info.kp_proc.p_flag 包含进程的标志,我们使用按位与运算符(&)检查 P_TRACED 标志是否被设置。如果该标志被设置(结果不等于 0),则表示该进程正在被调试,函数返回 true;否则,返回 false。
这段代码通过 sysctl 查询当前进程的 kinfo_proc 结构体,然后检查 P_TRACED 标志。如果 P_TRACED 标志被设置,则表示该进程正在被调试。
请注意,这种检测方法可能会受到攻击者的绕过,因为经验丰富的攻击者可能会使用更高级的技术,如修改 sysctl 的实现或使用其他调试接口。
修改 sysctl 的实现:攻击者可以使用动态库注入或其他代码注入技术,以便在运行时替换或修改 sysctl 函数的实现。这样,即使 App 使用 sysctl 来检测调试行为,攻击者仍然可以控制其输出,从而避免被检测。例如,攻击者可以使用以下代码片段来实现自定义的 sysctl 函数,将 P_TRACED 标志设置为 0:
1 | int custom_sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp, void *newp, size_t newlen) { |
然后,攻击者可以使用动态库注入或 Tweak 等将此自定义 sysctl 函数替换为 App 中的原始 sysctl 函数。
这里针对ptrace、sysctl、syscall来反反调试,做法就很简单了,hook函数,判断参数,返回结果。
1 | #import <substrate.h> |
因此,最好采用多层防御策略,并与其他安全措施(如代码混淆、加密、完整性检查等)相结合,以增强 App 的安全性。
通过设置异常处理函数,我们可以捕获调试器引发的异常(如断点、单步执行等),从而实现反调试功能。
1 | #include <signal.h>void signal_handler(int signal) { |
在 App 入口点调用 setup_signal_handler() 函数,即可设置异常处理函数。
对避免 dump 可能无直接效果,但可以提高 App 的安全性。
服务器端验证: 将关键功能和敏感数据存储在服务器端,通过 API 请求的方式进行访问,减少客户端的攻击面。
动态加载: 在运行时动态加载关键代码和资源,使攻击者无法直接从静态文件中获取敏感信息。
API 安全性: 采用 HTTPS 通信,对 API 请求进行签名验证,防止中间人攻击和 API 篡改。
多因素认证: 在关键操作中引入多因素认证机制,降低单一认证方式被破解的风险。例如短信验证码、人脸识别等。
对避免 dump 可能无直接效果,且对安全性不起作用,属于后置的方案策略。
1. 监控与告警: 实时监控 App 的运行状态,如发现异常行为或安全事件,及时触发告警,通知开发者进行处理。定期监控 SDK 的安全状况,收集安全事件和威胁情报。结合实时数据,对防护策略进行调整和优化。
2. 定期安全审计: 定期进行安全审计,检查 App 的安全状况,发现潜在的安全问题,并采取相应的措施进行修复。
3. 安全培训: 提高开发团队的安全意识和技能,确保在开发过程中能够充分考虑到安全因素,从而降低 App 被攻击的风险。定期进行安全培训,以便团队成员了解最新的安全威胁和防护措施。
随着科技的不断发展和进步,一直不断出现创新的安全技术方案,需要时刻关注行业动态,以便在安全挑战时更好地保护 App 的安全。
1. 人工智能与机器学习: 利用人工智能和机器学习技术自动检测代码中的安全问题,提高安全检测的效率和准确性。
2. 差分隐私计算: 隐私计算技术,如同态加密、安全多方计算等,可以在不解密数据的情况下进行数据处理和计算,从而在保护数据隐私的同时,实现数据的有效利用。
3. 自适应安全: 借助人工智能和机器学习技术,实现自适应安全系统,能够根据实时的安全状况和威胁情报,动态调整 App 的安全策略,更有效地防御攻击。
针对 App 或 SDK 安全,分析那些技术我们可能帮助我们提升安全性和预防篇安全风险。
以上所有 dump 方案,都是因为越狱导致可以破解,所以不能越狱就防止99%黑产。
建议:禁止越狱设备使用 App !!!
如果检测到越狱设备,您可以选择禁用某些功能或者限制 App 的使用。如终止app、删除敏感数据、隐藏某些功能等等。
实施方案
在 App 中添加越狱检测代码,以判断设备是否已经越狱。
另外,针对新的环境变化,如 Mac Catalyst 或 Designed for iPad 等环境,都可能运行 iOS App,需要开发者自行判断是否允许。
检查设备越狱的代码很多,以下是 GitHub 开源仓库 DTTJailbreakDetection 代码示例:
1 | + (BOOL)isJailbroken |
DeviceCheck 和 App Attest 是 Apple 提供的两个用于设备验证和 App 验证的 API。它们旨在提高 App 的安全性和保护用户隐私。
DeviceCheck API
DeviceCheck API 允许开发者在苹果服务器上存储每台设备的少量数据(两个位)。这可以用于识别设备是否曾经与您的服务器进行过交互,而无需获取设备的唯一标识符。
DeviceCheck 数据在 App 被删除和重新安装后仍然保持不变。这对于识别设备的唯一性非常有用。
为了使用 DeviceCheck API,您需要在开发者帐户中启用 DeviceCheck 功能,并在您的 App 和服务器端代码中集成相应的 API。
DeviceCheck 服务返回的两个位(bit0 和 bit1)是针对一台具体的 iOS 设备(iPhone 或 iPad)的,而不是与 Apple ID 账号关联的。这意味着,对于同一台设备上的不同 App ,这两个位都是相同的,而不是针对特定的 Apple ID 账号。这样,开发者可以使用这两个位来存储与特定设备相关的信息,如标记设备是否已经兑换过优惠券或是否参加过活动。
App Attest API
App Attest API 用于验证 iOS App 的完整性和真实性。它可以检测 App 是否被篡改或替换,并确认它是由可信赖的开发者发布的。通过使用 App Attest API,您可以确保您的服务器与真实、未经篡改的 App 进行通信。
App Attest API 为 App 提供了一个签名密钥,用于在 App 与开发者服务器之间的通信中生成签名。开发者服务器可以使用 Apple 提供的验证服务来验证签名,确保收到的请求来自于真实且未被篡改的 App 。
要使用 App Attest API,您需要在开发者帐户中启用 App Attest 功能,并在您的 App 和服务器端代码中集成相应的 API。
本报告探讨了防止 iOS dump 的可行性,讨论了几种提高 iOS App 安全性的策略,并强调了监测、审计和安全培训的重要性。报告还研究了一些新兴技术,如人工智能和差分隐私计算,这些技术有可能提高 iOS App 的安全性。最后,报告讨论了这些措施的局限性和挑战,并强调了需要进行持续的研究和开发,以进一步增强 iOS App 的安全性。
在应对 iOS SDK dump 的过程中,开发者需要关注多个方面的技术和策略,从防护到曲线救国,再到提高安全性,都需要采取综合性的措施。此外,随着科技的发展,未来将会出现更多创新的安全技术方案,为开发者提供更强大的安全保障。
要保护好应用程序的安全,开发者需要不断提高自身的安全意识和技能,关注新技术的发展,并将安全融入应用程序的开发、运行和维护全过程。同时,与安全领域的其他从业者保持紧密合作,共同应对不断变化的安全挑战,为用户提供安全、可靠的应用程序。
最后,需要强调的是,本报告的内容仅供参考,实际应用时可能需要根据具体需求进行适当的调整和优化。同时,攻击者可能会采取更复杂的手段绕过这些防护措施,因此开发者需要保持对安全领域的关注,持续改进和完善安全策略。
总之,本报告全面概述了iOS dump 预防,并提供了一系列提高 iOS App 安全性的策略。虽然这些措施的有效性存在一定局限性,但是显然,在安全技术领域进行持续的研究和开发将继续是未来 iOS App 安全的关键。
欢迎大家评论区一起讨论交流~
我们是37手游移动客户端开发团队,致力于为游戏行业提供高质量的SDK开发服务。
欢迎关注我们,了解更多移动开发和游戏 SDK 技术动态~
技术问题/交流/进群等可以加官方微信 MobileTeam37
]]>注:如若转载,请注明来源。
本文首发于 AppleParty(苹果派)v3 支持 App Store 新定价机制 - 批量配置自定价格和销售范围 - 掘金,欢迎关注我们 @37手游iOS技术运营团队 。
作者:iHTCboy
本文主要介绍了 AppleParty v3,一款方便开发者管理 App Store Connect 的工具。文章详细描述了新版本中支持的功能,如内购商品的批量上传、设置销售范围和价格机制等。作者还提到了 API 的一些限制和未来改进的可能性。若您对游戏行业有需求,如管理大量内购项目和多语言应用,AppleParty 可能是一个不错的选择。总之,本文为您提供了一个全面了解 AppleParty v3 的机会,以便更好地管理您在 App Store Connect 上的应用。
大家好!我们又见面啦,我们在上篇文章《使用 App Store Connect API v2.3 管理 App Store 新定价机制》讲解了关于 App Store 新定价机制 API 的介绍。但当时没有对 API 之间的关系性和联动进行介绍,有接口也不知道怎么串联起来使用。所以本文将详细介绍 App Store Connect API v2.3 如何实现批量配置自定价格和销售范围等。
首先,纠正一下我们之前文章《App Store 新定价机制 - 2023年最全版》提到 订阅类型价格调整 的影响,当时认为苹果全球均衡价格系统,会影响到自动续期订阅产品!但是仔细看 App Store Connect API 后发现,Apple 不会对你的自动续期订阅产品进行价格调整。
Apple 不会对你的自动续期订阅产品进行价格调整。Apple 可能会针对税务变化和重大汇率变动调整零售价格,但价格调整不涉及自动续期订阅。请注意,由于你的收益和 Apple 的佣金均在扣除增值税(VAT)之后计算,因此 VAT 税率变化会影响你的收益。你可以选择调整你的订阅价格,以减少税务或外汇变化对你的收益造成影响。
自动续期订阅产品,跟现有 App 和一次性 App 内购买项目的价格一样,不再使用价格等级,并且支持的价格点是一致的。但是自动续期订阅产品的价格,不能设置自动根据全球均衡价格系统调价! 这个就是区别,下文会详细介绍到~
在讲解 AppleParty(苹果派)支持 App Store 新定价机制之前,如果大家对 AppleParty(苹果派)不太了解,可以通过我们自己的文章学习,这里就不展开了。
使用批量内购商品配置,首先要更新到 v3.0.0 版本,登陆账号后选择 “我的 App”,然后点击 “上传内购项目”,打开内购管理内容:
首次,需要点击 下载表格示例
,下载模板表格,用于配置内购信息的信息。
打开示例表格,可以看到如下图所示例:
注意:
AppleParty
、PricePoints
、Territories
这 3 个工作表的名字不能更改,App 是根据这些名字来读取对应的内容。
帮助
工作表。test01.jpg
或 t01.png
。App Store 本地化版本
,可以配置多个语言版本,只需要在表格后面,表头添加对应的语言标识。下面是示例说明:
Product ID | 参考名字 | 应用内购买类型 | 审核截图(可选) | 审核备注(可选) | zh-Hans | zh-Hans | en-US | en-US |
---|---|---|---|---|---|---|---|---|
com.iap.01 | 测试suc1 | 消耗型 | test01.jpg | 中文名字01 | 中文描述01 | 英文名字01 | 英文描述01 |
示例表格中使用 zh-Hans
和 en-US
,在编辑内购商品的信息时,如果不需要这2种语言,可以删除或更改其它语言。需要注意,表格前面的几列,位置顺序不能更改,也不能删除列数等。上传到苹果 ASC 后台的效果:
App Store 本地化版本语言代码,可以查看表格的 帮助
工作表。例如日本是 ja
,在 AppleParty
工作表后面添加2列 ja
的表头,然后就可以配置对应的多语言。
审核截图的上传,下文会提到,这里暂时略过。
切换到 PricePoints
工作表,可以看到如下图所示例:
AppleParty
工作表的内购商品信息填写好后,直接复制过来。苹果各国家地区代码
工作表。部分国家和地区价格点
工作表,全部的国家和地区的价格点,请从苹果 ASC 后台下载。下面是示例说明:
Product ID | 基准国家(代码) | 基准国价格 | 自定价格国家1 | 自定价格1 | 自定价格国家2 | 自定价格2 | 自定价格国家3 | 自定价格3 | 自定价格国家4 | 自定价格4 |
---|---|---|---|---|---|---|---|---|---|---|
com.iap.01 | JPN | 100 | ||||||||
com.iap.02 | HKG | 10 | MAC | 1.9 | TWN | 65 | ||||
com.iap.03 | USA | 2.79 | KOR | 990 | CHN | 7 | LBR | 2.19 | COL | 6500 |
com.iap.01
:设置基准国家为 JPN
(日本),定价为 100
日元,而没有填写自定价格国家或地区,所以其余 174 个国家或地区,根据基准国家的 100 日元,苹果全球均衡价格系统自动调整对应的地区价格。com.iap.02
:设置基准国家为 HKG
(中国香港),定价为 10
港元,分别设置了中国澳门和中国台湾 2 个自定价格,其余 172 个国家或地区,根据基准国家的 10 港元,苹果全球均衡价格系统自动调整对应的地区价格。com.iap.03
:设置基准国家为 USA
(美国),定价为 2.79
美元,分别设置了4个国家或地区的自定价格,其余 170 个国家或地区,根据基准国家的 2.79 美元,苹果全球均衡价格系统自动调整对应的地区价格。总结:
苹果各国家地区代码
工作表。切换到 Territories
工作表,可以看到如下图所示例:
AppleParty
工作表的内购商品信息填写好后,直接复制过来。1
,则其它项的配置直接忽视,并且为 1 时,包含将来新国家/地区自动提供。如果值为 0
,则默认下架状态,然后根据其它项的配置来决定销售范围,见下一项的配置。在所有国家/地区销售
值为 1
,则此字段值固定为 1
。否则,此值为 1
表示将来 App Store 添加新国家/地区时自动提供销售,值为 0
表示将来新国家/地区不会自动提供销售。在所有国家/地区销售
值为 1
,则此字段设置无效。否则,填写一个或多个国家或地区时,则表示不会在所有国家/地区销售,只会在填写的国家和地区中上架销售。下面是示例说明:
Product ID | 在所有国家/地区销售(1是,0否) | 将来新国家/地区自动提供(1是,0否) | 销售1 | 销售2 | 销售3 | 销售4 | 销售5 |
---|---|---|---|---|---|---|---|
com.iap.01 | 0 | 1 | TWN | HKG | MAC | ||
com.iap.02 | 1 | 0 | |||||
com.iap.03 | 0 | 0 | USA | JPN | CHN | LBR | COL |
com.iap.04 | 0 | 1 | |||||
com.iap.05 | 0 | 0 |
com.bbbap.01
:当前只在 TWN
(中国台湾)、HKG
(中国香港)、MAC
(中国澳门) 销售,并且将来新国家/地区自动提供销售。com.bbbap.02
:在所有国家/地区销售,并且将来新国家/地区自动提供销售。com.bbbap.03
:当前只在 USA
(美国)、JPN
(日本)、CHN
(中国)、LBR
和 COL
销售,并且将来新国家/地区不提供销售。com.bbbap.04
:当前下架状态,直到将来有新国家/地区时自动提供销售。com.bbbap.05
:下架。关于这个销售范围的描述,在导入表格后,会显示对应的销售范围说明,参考下一章节内容。
点击 “导入表格”,可选择excel表进行导入,然后会显示导入的品项明细表:
首先,检查导入的数据,是否正确,包括 销售范围
和 价格机制
等。
然后,在右下角有 上传截图
按钮,点击导入图片。如下图:
截图是根据表格中填写的名字,匹配对应的图片文件,所以需要保证截图文件的名字和后缀一致,否则无法识别和上传。如果截图为空或错误,商品信息会正常更新,但截图不会更新。
左下角的 保留自动续期订阅者现有定价
,就是表示自动订阅商品,已经订阅的用户,如果价格调整的话,是否原有用户保持原订阅价格。如下图,是不保留原定价和保留的不同效果:
首次点击 提交
后,如未设置 API 密钥,会显示下面的界面:
首次需要设置,或者点击右下角 设置密钥
重新设置。密钥获取,参考我们之前的文章:App Store Connect API 密钥生成
最后,点击 提交
,会显示提交的日志输出:
上传失败时,查看 ❌
就是说明有异常或错误内容,需要自行判断是否正常:
1 | [04-18 10:12:50] 内购已经存在:com.tc.2 ,开始更新信息中... |
至此,批量内购创建和上传操作完成!✅
一个月
。不开启
。另外,近期会增加表格和苹果 ASC 后台商品的价格检查,用于检查配置价格是否正常。
最后,大家使用过程中,有任何疑问或建议,欢迎在评论区反馈。
从苹果 ASC 下载的价格点矩阵表,比如中国 customerPrice
为 1
,而通过 List all price points for an in-app purchase API 获取到的是 1.0
:
1 | "attributes": { |
所以,我们的表格上应该是填写 1
还是 1.0
呢?还有港元 10
,API 获取到的是 10.0
等。
答案是,都可以!怎么办到呢?
我们把价格,统一转换成保留 2 位小数的价格点,来保证价格点一致。
1 | /// 返回保留2位小数的价格格式 |
当然,眼尖的朋友,可能关注到一个字段 "priceTier": "10001"
,不是说没有价格等级了吗?怎么还有!!!理论上是没有了,但其实,苹果也是要保存这些价格之间的关系表,所以可以理解 priceTier 为价格点的 id。
那咱们不填写价格,用这个 priceTier
不就好了吗!理想很美好,现实很残酷!
当我调用自动续期订阅的 List All Price Points for a Subscription API 获取到的结果:
1 | "attributes" : { |
自动续期订阅的没有 priceTier
字段,所以你可能还有怀疑,咱们在看看 InAppPurchasePricePoint.Attributes 和 SubscriptionPricePoint.Attributes 文档,确实没有!
所以,关于价格点,应该怎么让运营同学定义,建议还是直接使用价格,简单明了!
苹果提供的更改内购的销售范围接口,只支持 availableInNewTerritories
,也就是是否将来新国家/地区自动提供!如果你需要支持全部的所有国家或地区,你只能把所有的国家代码,全部放到 availableTerritories
数组里!疯了吧!
最后,发现之前的 API Create an In-App Purchase 和 Modify an In-App Purchase 里有一个字段 availableInAllTerritories
,这样,如果我们希望在所有国家/地区销售,设置为 ture
就可以!注意,这里是包括了将来新国家/地区自动提供。
最后,可能就是我们会一直调试和测试一个或多个内购商品。然后,我们又想重新生成一次,想删除之前所有商品,在苹果 ASC 后台一个一个删除也不太现实,所以,还是写了一个脚本,一键自动删除所有:
1 | #!/usr/bin/env python3 |
最后,这个脚本也放到了我们 GitHub 仓库 37iOS/AppStoreConnectAPI-Demo,后续 API 升级都会一起更新,大家可以自行获取。
开发过程有很多细节文中没有提到,具体大家可以阅读源代码 37iOS/AppleParty,或者有遇到什么问题,欢迎评论区交流。
关于苹果 App Store Connect API 的问题,还是有很多优化的空间的。比如接口请求频率过快:
1 | Error code: RATE_LIMIT_EXCEEDED, title: The request rate limit has been reached., detail: Optional("We\'ve received too many requests for this API. Please wait and try again or slow down your request rate.") |
还有就是设置自定价格和销售范围,不支持增量修改!每次必然全量调用,如果有 20 个自定价格的国家或地区,那个自定价格每个请求 2 个,就 40 个请求了。如果有 100 个内购商品,就是 4000 次请求。所以,还是希望苹果后续能完善 API,支持更多场景的配置。
AppleParty 要解决的问题是开发者有很多 app 的情况下的管理,比如有多语言、频繁更新等,当然首要是对游戏行业的需求,比如内购买项目达到 100+ 个,人工一个一个创建显示无法满足,而且如今 App Store 新价格机制,需要看完 175 个国家和地区,已经不再现实!所以,如果团队没有精力打造一套工具流,AppleParty 也许是不错的选择!
以上就是 AppleParty v3 更新的简单介绍,大家可以在 GitHub 37iOS/AppleParty 查看详细的源代码。如果觉得不错,给我们点个赞!如有疑问或者问题,欢迎留言交流~
最后,Apple Party(苹果派)是一个新生儿,所以可能会存在很多缺陷,甚至不能满足所有的场景,这也是我们开源的目的,希望集大家的力量一起参与!也希望大家多担待和理解万岁,期待大家一起给项目提建议,提代码,一起好卷!
最后的最后,还是要重提一次,准备好迎接即将在 5 月 9 日推出的增强全球定价机制,2023 年 5 月 9 号还没有选择基础国家的 App 或 IAP(包含订阅产品),苹果会以美国为基准定价,直接影响:比如中国大陆销售的 6 元档位商品,按 1 美元换算会涨价到 8 元!
所以,现在马上配置吧!避免用户嫌贵!影响销量!
WWDC23 将于北京时间 6 月 6 日举行,让我们一起期待 Apple 全新的技术升级吧!我们也会第一时间进行解读和分享,欢迎关注我们,了解更多 iOS 和 Apple 的资讯~
]]>注:如若转载,请注明来源。
本文首发于 iOS SKAN 4.0 时代的广告追踪优化:掌握隐私友好的营销策略 - 掘金,欢迎关注我们 @37手游iOS技术运营团队 。
作者:ChatGPT(GPT-4) & iHTCboy
摘要:本文深入探讨了苹果的 SKAdNetwork(SKAN)以及它与 App Tracking Transparency(ATT)政策之间的关联,阐明了广告跟踪的限制以及如何在保护用户隐私的同时实现广告效果优化。文章还介绍了 SKAN 4.0 的新特性,以及提高用户 ATT 许可率和 SKAN 广告转化率的实用建议等。
小编早就想撰写一篇关于苹果 iOS 端广告跟踪历史的文章,可是一直没有抽出时间来完成。直到最近,开始使用 ChatGPT(GPT-4),突然发现写文章变得轻松许多。现在,我可以轻松地连续爬(写)上五楼(五千字),都不会喘不过气来。
接下来,我将带领大家穿越时光,详细回顾 iOS 端 IDFA 和 ATT 广告跟踪的发展历程。我们将从早期的广告追踪方法开始,探讨其中的挑战和不足之处,再了解苹果如何引入更先进的技术和策略,以应对日益增长的隐私和安全问题。此外,我们还将讨论广告跟踪技术未来的发展趋势,以及它们将如何影响广告行业的格局。希望这篇文章能为您提供有关 iOS 广告跟踪的全面了解,同时激发您对广告领域的兴趣,研究和实现更加安全和有效的广告和确保用户隐私得到保护的广告模式或技术。
有一个小插曲,ChatGPT 数据目前只到 2021 年 9 月,所以需要给它 “喂” SKAN 4.0 的数据饲料,才能让它了解最新动态:
2020 年苹果在 WWDC20 推出 iOS 14 和 ATT
(App Tracking Transparency
, 应用追踪透明度)框架,旨在最终全面关闭 IDFA。简单来说,苹果把 IDFA 是否允许 app 获取的权限交给了用户来选择。
而 IDFA 是什么?在 iOS app 中,苹果提供 IDFA
(Identifier For Advertisers
,广告标识符) 来确实用户。为了保护用户隐私,早在 2012 年苹果公司就不再允许其生态的 App 获取用户的唯一标识符,但是商家在移动端打广告的时候又希望能监控到每一次广告投放的效果,因此,苹果想出了折中的办法,就是提供另外一套和硬件无关的标识符,用于给商家监测广告效果,同时用户可以在手机中重置这个广告标识符,避免商家长期跟踪用户行为。但一般用户对此无感知(不会关闭),IDFA 准确率非常高。
而现在苹果推出 ATT,把 IDFA 的获取放到台面上,让用户选择是否允许 app 获取 IDFA。从目前的行业数据来看,用户允许 ATT 广告跟踪权限只有不到 30%。也就是说,广告跟踪的准确率远远低于 30%,这对于广告投放效果来说,是无法接受的!因为投放的广告不能看到效果,这是广告投放最可怕的事,投了钱不能看到效果,是亏还是赚还要靠猜???
虽然基于广告行业的压力,但苹果最终还是于 2021 年 4 月 27 日发布 iOS 14.5,并增加强制的 ATT 权限功能,App 必然要用户允许 ATT 权限后,才能获取用户设备的 IDFA。至此,IDFA 名存实亡!!!
App Tracking Transparency(ATT)政策要求应用在收集用户数据或将数据共享给第三方广告平台之前,必须获得用户的明确同意。这意味着在应用中,开发者需要向用户展示一个弹出窗口,向用户解释为什么要收集这些数据以及如何使用它们。这一政策限制了许多传统广告追踪方式,因为它们通常在用户不知情的情况下收集和共享用户数据。
随着个人隐私意识的不断提高,苹果公司认为有必要保护用户的隐私,让他们有权决定自己的数据是否被收集和共享。通过实施 ATT 政策,用户可以选择是否允许应用追踪他们的数据。这有助于提高用户对数据使用的信任和透明度。
作为开发者或广告商,您需要遵循以下步骤来适应和使用 ATT 政策:
跟踪用户设备的目的是什么?最原始的目的是 广告归因
。他们希望将购买归因于广告点击,以便商家知道将广告预算集中在哪里,此类归因用于衡量哪些广告有效。但随着移动端成为全球用户必备的随身设备,单单的广告归因已经不能满足他们的目的,收集购买习惯以及其他隐私信息,它们变得比你自己更了解自身的购买需求!
苹果推出的 SKAdNetwork
就是希望在广告端袜掉用户的标识,各 app 之间的用户标识,要不要共享给第三方使用,应该由用户自己来决定。App 获取 IDFA 广告标签符前需要调用 ATT 授权弹窗来求用户许可:
那以后怎么投放广告呢?苹果给出的方案是,使用 SKAdNetwork !
SKAN 是 SKAdNetwork 的简称,是 Apple 推出的一个隐私保护的广告解决方案。随着 Apple 对用户隐私保护的关注度越来越高,尤其是通过引入 App Tracking Transparency(ATT)政策,SKAdNetwork 的重要性得到了凸显。
SKAdNetwork 是一项用于在 iOS 设备上衡量应用广告效果的解决方案。它允许广告网络和开发人员在不暴露用户个人信息的情况下跟踪广告活动的效果。SKAdNetwork 通过聚合数据,而不是提供用户级别的数据,从而确保用户隐私得到保护。
随着苹果对用户隐私的关注不断加大,通过 ATT 政策限制了许多传统的广告追踪方式
SKAdNetwork 是可以在保护用户隐私的前提下衡量广告效果的解决方案。广告商、开发者和广告平台都需要适应这一变化,以便在 iOS 生态系统中继续提供有效的广告服务和衡量广告投放效果。
在App Tracking Transparency(ATT)政策实施之后,应用开发者和广告商在 iOS 设备上进行广告追踪的方式受到了限制。在不使用 ATT 和 SKAdNetwork(SKAN)的情况下,进行广告追踪变得困难,因为这违反了苹果的隐私政策。
然而,在其他平台(如 Android、Web 等)上,广告追踪仍然可以使用其他方法。以下是一些在其他平台上可以使用的广告追踪方法:
总之,在 iOS 设备上,在不使用 ATT 和 SKAN 的情况下进行广告追踪变得越来越困难。然而,在其他平台上,广告商仍然可以使用 Cookie、设备指纹技术和统一登录等方法进行广告追踪。需要注意的是,随着隐私法规的不断更新和收紧,这些方法也可能受到限制。为了应对这些变化,广告商和开发者需要密切关注行业动态,并考虑转向更加隐私友好的广告解决方案。
我们用一个比喻来解释 SKAdNetwork 的原理:假设一个快递公司代表了广告网络,而用户安装应用程序就像收件人接收包裹。在这个例子中,SKAdNetwork 就像一个保护用户隐私的隐形屏障。快递公司(广告网络)可以知道包裹(广告点击和安装事件)已经被成功投递,但是并不能知道具体是哪个收件人(用户)收到了包裹。通过这种方式,SKAdNetwork保证了用户隐私得到了保护,同时广告商仍然可以衡量广告效果。
SKAdNetwork 是苹果为了保护用户隐私而推出的一种广告效果衡量系统。它允许广告网络以去中心化的方式追踪用户安装和使用应用程序,而无需访问用户的唯一标识符。SKAdNetwork 使用加密签名和一系列预定义参数传递广告点击、安装和转换数据。在整个过程中,个人信息得到了保护,不会泄露给广告商或广告网络。
所以 SKAdNetwork 归因数据本身不具有任何用户标识符,所以无法跟踪用户。SKAdNetwork 是让广告平台在不获取 IDFA 的前提下,对用户的点击和安装行为提供的一套追踪解决方案。由于 Apple 的介入,将直接横跨设备与 App Store,并且不会把任何设备信息透露给广告主,并且更有利于防作弊。
当用户点击广告时,一个带有签名信息的 App Store 产品界面呈现出来,签名信息标记了此次广告活动。如果用户安装并且打开了 app,设备发送一个安装验证通知给广告网络。这个由 Apple 签名的通知包括广告活动 ID,但是不含用户或设备相关的数据。通知还可以包含一个转化数值和来源应用 ID,这个取决于苹果设定的一个隐私阈值。
要使用 SKAdNetwork,开发者和广告商需要按照以下步骤操作:
SKAdNetwork 最大的问题就是提供了聚合的数据,但对于广告来说,这个过程已经不是简单的跟踪用户,而跟踪广告也是非常的重要,因为一个广告可能有多个不同的素材和不同的渠道测试等。
通过 SKAdNetwork 回传通知可以获取的 数据 :
SKAdNetwork 2.0
1 | { |
SKAdNetwork 3.0
1 | { |
SKAdNetwork 4.0
细粒度转化值的情况:
1 | { |
粗粒度转化值的情况:
1 | { |
字段说明:
字段名 | 解析 | 支持的版本 |
---|---|---|
app-id | 投放广告的 App Store App ID | - |
ad-network-id | 广告平台 ID。 | - |
transaction-id | 用于转化验证,去重安装验证回传。 | - |
version | SKAdNetwork 版本号 | 2.0 及更高版本。 |
campaign-id | 记录广告活动 campaign 的标识符信息。4.0 及更高版本的广告使用 source-identifer 替代。 | 1.0 ~ 3.0 版本使用,4.0 版本弃用。 |
attribution-signature | 您需要验证的 Apple 的归因签名。 | 2.0 及更高版本。 |
redownload | 是否重复下载 | 2.0 及更高版本。 |
source-app-id | 从哪个 app 上看到广告且安装的 | 2.0 及更高版本。 |
conversion-value | 转化值。只有当已安装的 app 提供转换值,并且提供参数满足苹果的隐私阈值时,conversion-value 才会出现在回传中。 | 2.0 及更高版本。 |
fidelity-type | 值为 0 表示页面展示类型的广告;值为 1 表示 StoreKit 渲染的广告或 SKAdNetwork 归因的 Web 广告。 | 2.2 及更高版本 |
did-win | 如果广告网络赢得归因,则为 true,如果回传代表没有赢得归因的合格广告效果,则为 false。(注意:只有为 ture 时,才会包含字段 source-app-id 和值。) | 3.0 及更高版本 |
source-identifier | 取代 campaign-id 的分层来源标识符。此字符串表示原始值的两位数、三位数或四位数。 | 4.0 及更高版本 |
source-domain | 仅适用于 Web 广告。SKAdNetwork for Web Ads 投放广告的来源域名,字段值与 source-app-id 是对立,两者只会返回其一。 | 4.0 及更高版本 |
coarse-conversion-value | 粗粒度的转换值,可能的值为字符串 “low”、”medium” 和 “high”。系统在较低的回传数据层以及第二次和第三次回传中发送该值,且不会返回转化值(conversion-value)。 | 4.0 及更高版本 |
postback-sequence-index | 可能的整数值 0、1 和 2。分别表示由三个转换窗口产生的回传顺序。 | 4.0 及更高版本 |
注:
conversion-value
: 无符号的 6 bit 整数(也就是只能为 0-63 的数字)。由广告主应用和广告网络决定此值的含义。默认为 0。所以,因为数字太小,无法绑定到用户信息。source-identifier
(影响回传返回的位数)coarse-conversion-value
conversion-value
source-app-id
source-domain
以上字段的详细说明文档:Identifying the parameters in install-validation postbacks
转换窗口(Conversion Window
)是广告投放与广告效果(如应用安装、购买等)之间的时间间隔。它用于衡量用户在看到或点击广告后多长时间内完成了特定的目标动作。转换窗口可以帮助广告商和开发者了解广告活动的效果,并据此调整广告策略。
SKAdNetwork(SKAN)的转换窗口与传统转换窗口有所不同。在 SKAN 中,转换窗口不再是实时的,因为它采用了聚合和延迟报告的方式来保护用户隐私。这意味着,SKAN 不会立即将转换事件报告给广告商,而是在一个随机的时间窗口内发送回传报告。
SKAdNetwork 4.0 引入了三个转化窗口,最多可以为每个获胜广告归因产生三个回传。第一个转化窗口为 0 至 2 天,第二个窗口为 3 至 7 天,第三个窗口为 8 至 35 天。在这三个窗口期间,app 可以更新转化值。
当 app 在转化窗口结束之前锁定(locked conversion
)并最终确定转化值时,系统会在随机延迟后发送回传。首次回传的随机延迟为 24-48 小时,第二次和第三次回传的随机延迟为 24-144 小时。
以前称为广告系列 ID 栏位。通过来源标识栏位,广告商可以确定安装归因于哪个广告系列,还能获得其他归因信息。广告商可以根据其目标来配置这个四位数的值,例如广告系列价值、广告投放位置或广告创意类型。
在回传中,分层来源标识栏位始终包含至少两位数字。最多可包含四位数字,具体取决于广告系列所带来的安装数量和回传数据层。例如,如果广告系列没有产生足够的安装数量,则回传的来源标识栏位中只会出现两位数字。这为广告商提供了更多的广告系列灵活性,并可在满足隐私阈值时提供更多归因洞察,同时保护跨 App 的用户隐私。
转化值可以是粗粒度值,也可以是细粒度值。虽然这两个值都是在衡量窗口期间捕获的,但最终值由广告系列所带来的安装数量和回传数据层决定。当广告系列带来的 App 安装数量较少时,广告商将获得仅包含有限归因信息的粗粒度值。粗粒度值可以是低、中或高。
SKAdNetwork 4.0 引入的隐私阈值变更,使得从 SKAdNetwork 回传数据中获取的空值(nulls)变得更少。
在之前的 SKAdNetwork 版本中,根据 Apple 的隐私政策,当达到一定隐私阈值时,某些回传数据可能会被设为 null。这意味着广告网络在某些情况下可能无法获取足够的数据来衡量广告效果。
在 SKAdNetwork 4.0 中,Apple 调整了这些隐私阈值,使得回传数据中的 null 值更少。这有助于广告网络获得更多有用的数据,从而更好地衡量广告效果,同时仍然保护用户隐私。这种调整使广告网络能够在保护用户隐私的前提下,更好地优化广告策略和投放效果。
为了维护用户隐私并确保群体匿名性,设备可能会限制 SKAdNetwork 在回传数据中发送的数据。Apple 为每个应用下载分配一个回传数据层级。以下关系图描述了回传数据层级与相对群体大小之间的关系(仅供示例):
为了保护用户隐私,回传数据分为四个层级(Tier 0、Tier 1、Tier 2 和 Tier 3),每个层级表示不同大小的群体。Tier 0 代表最小的群体,Tier 3 代表最大的群体。
回传数据层级考虑了显示广告的应用或域名、广告应用以及广告网络提供的分层源标识符(source-identifier)相关的群体大小。系统计算两位数、三位数和四位数分层源标识符的回传数据层级,并选择具有最高回传数据层级的源标识符。如果多个源标识符具有相同的最高回传数据层级,系统将选择具有最多位数的源标识符。如果最高的回传数据层级是 Tier 1 或 Tier 0,系统始终选择两位数的源标识符。
层级 | 群体大小 | source-identifier | 转化值 | 用户隐私保护 |
---|---|---|---|---|
Tier 0 | 最小 | 两位数 | 粗粒度 (低) | 最高 |
Tier 1 | 较大 | 两位数 | 粗粒度 (中) | 较高 |
Tier 2 | 更大 | 两位数或更多位 | 粗粒度 (高) | 较低 |
Tier 3 | 最大 | 三位数或四位数 | 细粒度 | 最低 |
回传数据层级会影响回传中的以下字段,这些字段可能存在、不存在或只包含其中部分的值:
source-identifier
(分层来源标识符),影响回传返回的位数,导致可能返回两位数、三位数或四位数。conversion-value
(细粒度转换值),仅在第一次回传中可用。coarse-conversion-value
(粗粒度转换值),在较低回传数据层级以及第二和第三次回传中,系统发送此值而不是 conversion-value。source-app-id
(显示广告的 App id)或 source-domain(显示网页广告的域名)。注意:
SKAdNetwork 支持对 Safari 浏览器中的网页广告进行归因。用户轻点这类广告后,会转至广告中所推广 App 的 App Store 产品页面。除 App 内广告外,广告商现在还能使用私人点击衡量对网页广告进行归因。
要在网页创建 SKAN 归因广告链接时,需要遵循以下特定格式:
1 | <a href="<https://apps.apple.com/app/id{itunes_item_id}>" |
这个格式中包含了以下几个值:
{itunes_item_id}
:广告宣传的应用的 App Store App ID。attributionDestination
:广告网络的有效顶级域名和一个前导域名组件(eTLD+1)表示。此值需要与获取已签名的网络广告展示负载请求和响应中的 source-domain
值匹配。attributionSourceNonce
:为每个广告展示生成的一次性 UUID 值的 Base64URL 编码表示。您需要根据实际情况填写这些值。当用户点击广告链接时,将会生成一个 AdImpressionRequest,设备会使用这些信息从 Web 广告链接中获取完整的 SKAdNetwork 归因信息。
注:有效顶级域名(eTLD)是互联网域名系统(DNS)中的最高级别域名。例如,对于 example.com,有效顶级域名就是 .com。一个前导域名组件(eTLD+1)表示有效顶级域名加上紧邻的一个子域名。例如,在 example.com 中,eTLD+1 就是 example(前导域名组件)+ .com(有效顶级域名)。
例如,如果广告网络的域名是 ads.example.com,那么
attributionDestination
应为https://example.com
。这样,SKAdNetwork for Web Ads API 才可以识别并将广告归因于正确的广告网络。
因为这个是广告商来处理,所以我们这里就不展开了。有兴趣的朋友,可以查看 苹果文档。
提高用户在 App Tracking Transparency(ATT)政策下的许可率是广告商和应用开发者关注的重点。以下是一些建议,可帮助您在遵循隐私政策的同时提高用户许可率:
通过遵循上述建议,您可以在遵循 App Tracking Transparency(ATT)政策的同时,提高用户许可率。要记住,建立用户信任和提供优质的应用体验是提高许可率的关键。
答:它不能追踪到具体的某个用户, 这是因为它的设计初衷就是在保护用户隐私的前提下,提供广告效果数据。
SKAN 的工作原理是通过聚合数据,而不是提供用户级别的数据。这意味着广告商可以了解广告投放效果和转化情况,但无法识别这些数据来自哪个具体的个体。SKAN通过发送不包含设备或用户身份信息的转化报告,确保用户隐私得到保护。
此外,SKAN 还对数据进行了延迟发送,以降低将数据与特定用户关联的可能性。这种延迟发送有助于确保广告效果数据不能用于识别个体用户。
总之,SKAdNetwork(SKAN)无法追踪到具体某个用户,因为其设计初衷是在保护用户隐私的前提下,提供广告效果数据。通过聚合数据、不提供用户级别的数据以及延迟发送数据,SKAN确保用户的隐私得到了保护。
SKAdNetwork(SKAN)的设计目的是在保护用户隐私的前提下提供广告效果数据,因此其本身并不支持追踪具体某个用户。尝试使用 SKAN 追踪到具体某个用户不符合苹果的隐私政策,这可能导致您的应用受到限制或从 App Store 中移除。
值得注意的是,随着隐私保护意识的提高和相关政策的收紧,应用开发者和广告商需要遵循相关法规,确保用户隐私得到保护。在这种情况下,建议您专注于使用SKAN等隐私保护的解决方案来衡量广告效果,并尊重用户的隐私选择。
在不侵犯用户隐私的前提下,您可以尝试采用其他方法来优化广告效果:
总之,使用 SKAN 追踪具体某个用户并不符合其设计目的和苹果的隐私政策。建议您遵循相关法规,确保用户隐私得到保护,并在此基础上优化广告策略和应用体验。
使用 SKAdNetwork(SKAN)时,有一些注意事项需要遵循,同时可以采用一些策略来提高广告转化率。
注意事项:
提高转化率:
通过遵循上述注意事项和策略,您可以在使用 SKAdNetwork(SKAN)的过程中更好地遵守苹果政策,同时提高广告转化率。
首先粗粒度转化值(coarse-conversion-value
)和分层来源标识(source-identifier
)没有直接关系。它们都是 SKAdNetwork 回传中的两个参数,它们分别表示粗粒度的转化值和广告来源信息。source-identifier
是用于表示广告来源的标识符,它可能包含两位数、三位数或四位数。这个参数的位数并不直接对应粗粒化转化值的级别(低、中、高)。coarse-conversion-value
是用于表示粗略的转换值,它有三个可能的值:低、中、高。这个参数是为了在低回传数据层级中保护用户隐私而引入的,它不能直接从 source-identifier
的位数推导出来。
对于高回传数据层级:
source-identifier
,表示精确的广告来源信息。conversion-value
,表示细粒度的转化值。对于低回传数据层级:
source-identifier
,表示模糊的广告来源信息。coarse-conversion-value
,而不是具体的 conversion-value
。在低回传数据层级的示例中,coarse-conversion-value
的值为 “high”。这里的 “high” 是一个相对描述,表示该回传所代表的广告转化效果相对较高。不同的粗略转换值可以用来区分广告效果的不同范围,例如 “high
“、”medium
“ 和 “low
“。简而言之,粗粒度的转化值(coarse-conversion-value)是一个相对概念,用于表示广告效果的大致范围。在低回传数据层级中,由于保护用户隐私的需要,不提供精确的转化值和广告来源信息。
可以将这种关系比喻为一个产品销售报告:
source-identifier
类似于报告中的销售渠道。在高回传数据层级中,它可能表示一个特定的商店编号(例如:编号 1234 的商店),而在低回传数据层级中,它只包含粗略的信息(例如:地区编号 12,表示某个地区的所有商店)。coarse-conversion-value
类似于报告中的销售额区间。在高回传数据层级中,您可以获得确切的销售额(例如:销售额为 10,000 美元),而在低回传数据层级中,您只能获得一个大致的范围(例如:”high”,表示销售额较高,但不提供具体数值)。因此,在低回传数据层级中,source-identifier
和 coarse-conversion-value
一起为您提供了模糊的广告效果信息,同时保护了用户隐私。
source-identifier
是一个分层源标识符,它可能包括两位数、三位数或四位数。不同的位数表示不同层级的信息,例如:
注意:苹果官方文档并未明确规定 source-identifier 的第三位和第四位分别代表地理位置和广告投放位置。实际上,苹果没有对 source-identifier 的具体组成部分做出明确的规定。source-identifier 是由广告网络自行确定的,用于识别不同广告来源的标识符。
这种分层标识符有助于广告网络和开发者更好地了解广告效果,并依据这些信息来优化广告策略。同时,SKAdNetwork 也确保了在回传数据时保护用户隐私。
对于 source-identifier 的第 3 位和第 4 位,理论上它们都可以是 0-9。然而,在实际应用中,如何划分这些数字以表示地理位置和广告投放位置是取决于广告网络的实际需求和策略的。您可以将最后两位组合为 00~99,从而得到 100 个不同的组合来表示更多的信息,但这取决于广告网络如何设计和使用这些位数。具体的实现可能因广告网络和实际需求而异。
如果广告网络在 source-identifier 中使用了四位数字,您可以将最后两位组合为 00~99,从而得到 100 个不同的组合来表示更多的信息。但如果您只收到回调中的三位数字,那么您将无法获得全部的四位数字信息,因此可能无法完全匹配和解析所有的数据。
所以,广告网络和开发者可以根据自己的需求自行定义 source-identifier 的层次结构。在某些情况下,根据回传数据分层,回传中可能只包含部分 source-identifier 信息。因此,确保广告网络和开发者之间的沟通和协调,以便正确解析和处理回传数据。
总之,SKAdNetwork(SKAN)是苹果推出的一种在 iOS 设备上衡量广告效果的解决方案,是目前 iOS 苹果官方最可靠的广告方案。在当前强调用户隐私保护的环境下,广告商、开发者和广告平台需要适应这一变化,以便在 iOS 生态系统中继续提供有效的广告服务。
本文的创作得力于 ChatGPT 的智能辅助,GPT-4 的表现如此出色,读者们应该难以分辨哪些内容是由 ChatGPT 创作,哪些是小编书写?这充分体现了 AI 技术在协同创作中的巨大潜力,为广大创作者提供了更为高效和便捷的创作方式。
此次合作既展示了 AI 的强大能力,也为未来人工智能与人类创作者的协作开辟了广阔的可能性。让我们期待更多类似的卓越成果,共同见证 AI 技术在创作领域的蓬勃发展!
欢迎大家评论区一起讨论交流~
欢迎关注我们,了解更多 iOS 和 Apple 的动态~
]]>注:如若转载,请注明来源。
本文首发于 使用 App Store Connect API v2.3 管理 App Store 新定价机制 - 掘金,欢迎关注我们 @37手游iOS技术运营团队 。
作者:iHTCboy
我们在上一篇文章 《App Store 新定价机制》讲解了苹果新定价升级,本文接着来讲解一下新 App Store Connect API v2.3 的使用示例。
关于 App Store Connect API 的基本使用和密钥创建,可以直接参考我们之前的文章 《使用 App Store Connect API 批量创建内购商品》,这里就不重复展开了。我们直接来给出请求的示例和说明啊。
关于 App Store Connect API version 2.3 release notes,所有请求示例代码和响应内容,已经上传到 GitHub 仓库:
App Store Connect API v2.3 更新的内容:
因为以下的很多接口,都依赖这个接口获取到的国家或地区标识,所以先讲解。这个接口是 v1.2 就有的基础接口,作用是获取 App Store 目前允许销售的所有国家和地区。
GET 请求:
1 | GET https://api.appstoreconnect.apple.com/v1/territories?limit=200 |
返回的内容,其中的中国大陆是这样:
1 | { |
目前苹果支持 175 个国家和地区,所以在请求链接增加 ?limit=200
,就可以不用分页,直接返回全部的内容。另外,如果是自定 App,允许的销售国家地区与 App Store 不相同,获取接口是 List All Territories for an End User License Agreement,需要了解的可以自行查询。
1 | GET https://api.appstoreconnect.apple.com/v1/apps/{id}/appPricePoints?filter[territory]=CHN&include=territory&limit=200 |
返回的内容:
1 | { |
苹果说这个接口会返回 900 个价格点,目前只返回 801 个,其中包含一个 0.0
免费价格点。
1 | "attributes": { |
另外,还有 100 个高价格点,估计是向苹果申请通过后,接口才会返回。
如果不加 ?limit=200
最大额分页的话,所有的国家和地区的价格点,有 140175 个:
1 | "meta" : { |
加上 ?limit=200
有 700 分页,所以你需要请求 700 次!在使用时建议还是按国家和地区码分别一个一个获取,如 filter[territory]=CHN
只获取中国大陆的价格点,因为减少请求分页量比较方便管理。那么如果请求超过 200 个时,应该怎么分页请求呢?
通过 next
字段来请求下一页,里面有一个 cursor
字段,表示下一页的游标,是不是有点傻?按道理说,用 offset=2
会不会更好一点?
1 | "links" : { |
next
字段就是请求下一页的请求链接,如果开发者不想记录整个链接内容,可以只保存 表示下一页的游标的字段 cursor
值。
当然,奇葩的事情,Apple Server API 接口的分页逻辑是:hasMore
和 revision
或 paginationToken
,例如 “&paginationToken=45380b30-5ed1-11ed-8aba-e1f7e9604fd2"
,如此不统一的接口请求方式,充分说明这肯定是两个团队在搞事!
注意这个接口需要的 {id}
参数,是 App 的价格点接口获取到的价格点 id,例如 eyJzIjoiMTI0MDg1Njc3NSIsInQiOiJDSE4iLCJwIjoiMTAwMDEifQ
。
1 | GET https://api.appstoreconnect.apple.com/v3/appPricePoints/{id}?include=app,territory |
默认请求返回的内容:
1 | { |
加上参数 ?include=app,territory
才能获取到对应的国家或地区码,比如价格点人民币 1.0 元,对应的 id :
1 | { |
这个接口的作用是方便根据某个价格点,反查货币种类和 app 信息等。另外有 100 个高价格不是所有 app 默认支持,所以通过反查可以获取 app 信息。
注意这个接口的 {id}
参数,也是 App 的价格点接口获取到的价格点 id。
1 | GET https://api.appstoreconnect.apple.com/v3/appPricePoints/{id}/equalizations?include=app,territory |
返回的内容示例:
1 | { |
返回的是剩下 174 个国家或地区的对应价格点的均衡价格。
注意:这个接口是 app 的全球均衡价格点查询,IAP 内购的接口暂时未发现苹果有提供,但 v2.0 版本苹果提供了订阅商品的全球均衡价格点接口:List All Subscription Price Point Equalizations。
1 | GET https://api.appstoreconnect.apple.com/v2/inAppPurchases/{id}/pricePoints?filter[territory]=CHN&include=territory&limit=200 |
注意接口的 {id}
是内购商品 id,可以通过接口 List All In-App Purchases for an App 获取某个 app 的所有 IAP id。
字段 filter[territory]=CHN,USA
拼接多个字段,这时可以返回多个地区的价格点。另外,如果需要知道返回的价格点是那个国家或地区的,需要带上 include=territory
,否则不会显示国家或地区码。
最终返回的内容示例:
1 | { |
同时,这个接口返回 800 个价格点,100 个高价格点申请通过的 IAP 商品才支持。另外IAP 内购商品没有 0.0
免费的价格点。
1 | GET https://api.appstoreconnect.apple.com/v1/apps/{id}/appPriceSchedule?include=app,automaticPrices,baseTerritory,manualPrices |
返回内容:
1 | { |
返回的内容包含 3 部分:
1 | GET https://api.appstoreconnect.apple.com/v1/appPriceSchedules/{id}?include=app,automaticPrices,baseTerritory,manualPrices |
这个接口返回内容与上一个接口一样,所以这里省略,暂时不明确为什么会这样。
1 | GET https://api.appstoreconnect.apple.com/v1/appPriceSchedules/{id}/automaticPrices?include=appPricePoint,territory&limit=200 |
返回内容,示例:中国香港的价格设置为手动调整价格,且价格于 2023 年 4 月 20 日结束,系统就变成“自动调整”:
1 | { |
注意:通过开始时间和结束时间,有可能总的条数 total 超过 174 个国家或地区。还有外汇汇率或税率调整等因素。全球均衡价格时间表比较复杂,大家可以自己在 ASC 后台配置不同价格规则,然后观察接口返回的内容。
1 | https://api.appstoreconnect.apple.com/v1/appPriceSchedules/{id}/manualPrices?include=appPricePoint,territory&limit=200 |
响应内容示例:
1 | { |
1 | GET https://api.appstoreconnect.apple.com/v1/appPriceSchedules/{id}/baseTerritory |
响应内容示例:
1 | { |
如果没有设置基准国家的新 app,默认是美国为基准国家:
1 | { |
1 | POST https://api.appstoreconnect.apple.com/v1/appPriceSchedules |
请求体:
1 | #基准国家 |
关于这个请求的参数和解析,请参考本文的 2.16 章节《2.16 设定某个 IAP 的价格调整(IAP 级别)(Add a scheduled price change to an in-app purchase)》,因为请求相同,所以统一在后文中解析。
注: 这个接口是 v2.0 版本就有,从查询到的内容来看,返回的只是 manualPrices
自定价格的信息。
1 | GET https://api.appstoreconnect.apple.com/v1/inAppPurchasePriceSchedules/{id}/manualPrices?include=inAppPurchasePricePoint,territory |
响应示例:
1 | { |
注: 这个接口是 v2.0 版本就有,返回的内容包含基准国家、全球均衡国家和自定价格的时间表。
1 | GET https://api.appstoreconnect.apple.com/v1/inAppPurchasePriceSchedules/{id}?include=automaticPrices,baseTerritory,manualPrices |
响应示例:
1 | { |
1 | GET https://api.appstoreconnect.apple.com/v1/inAppPurchasePriceSchedules/{id}/automaticPrices?include=inAppPurchasePricePoint,territory&limit=200 |
响应示例:
1 | { |
1 | GET https://api.appstoreconnect.apple.com/v1/inAppPurchasePriceSchedules/{id}/baseTerritory |
响应示例:
1 | { |
注: 这个接口是 v2.0 版本就有,是原有配置 IAP 内购价格的接口,苹果在原接口的基础上,增加了字段 baseTerritory
表示基准国家。
1 | POST https://api.appstoreconnect.apple.com/v1/inAppPurchasePriceSchedules |
请求体:
1 | { |
其中的请求字段的含义:
app_iap_id
:内购商品的标识 id,ASC 后台叫 Apple ID
,如 6444653105
base_territory_id
:基准国家或地区,例如中国大陆,CHN
,中国香港 HKG
iap_price_id
:随意名字,用于区别一个价格计划,如 我是1.00人民币计划
iap_price_point_id
:通过内购价格点列表(本文章节 2.5 获取内购 IAP 的价格点)获取,如 CNY¥ 1.00 的价格点 id 是 “eyJzIjoiNjQ0NDY1MzEwNSIsInQiOiJDSE4iLCJwIjoiMTAwMDEifQ”。上面的请求,是表示设置基准国家,并且设置全球均衡价格,注意,这里默认设置全球所有的国家和地区。如果是想某个国家或地区设置自定价格,请求示例:
1 |
|
这个示例表示,以中国大陆 CHN
为基准国家,并且设置所有国家和地区都是自动全球均衡价格,除了中国香港 HKG
。然后从现在到 2023-04-25
,使用基准国家中国大陆的 CNY¥ 2.50
价格点设置全球均衡价格,从 2023-04-25
开始,使用基准国家中国大陆的 CNY¥ 1.00
价格点设置全球均衡价格。例外的是中国香港,从现在开始一直是手动调整 自定价格
HKD $16.00
,也就是固定价格,不跟随全球均衡价格调整。
这里坑比较多,baseTerritory
基准国家字段必须设置,否则会报错:
1 | { |
然后 manualPrices
字段虽然是手动价格的意思,但并不是自定价格的意思,表示所有需要设定的价格时间表计划,这里我们设置了 3 个价格时间计划:
1 | 'manualPrices': { |
上面的 id
表示价格时间计划表的名字,用于区别每个时间计划表。然后接着,就是要列表具体的价格时间表:
1 | 'included': [ |
这里最复杂的是 2 个地方,included.x.id
和 manualPrices.data.x.id
是一一对应,所以有一个价格时间计划表,就有对应的一个 included.x.id
,它们跟 relationships.inAppPurchasePricePoint.data.id
是没有关联的,当然如果你觉得方便,把三者都设置为价格点的 id 也是可以。
注意 included.x.id
数组列出的价格时间计划表,必然在 manualPrices.data.x.id
在列出,否则报错:
1 | { |
relationships.inAppPurchasePricePoint.data.id
需要设置为对应需要的国家或地区的价格点 id,这里是中国大陆,所以设置为 CHN
对应的价格点。而需要自定价格的国家或地区,则就需要设置对应国家或地区的价格点。(内购价格点列表:参考本文章节 2.5 获取内购 IAP 的价格点)
另外需要注意,基准国家的价格时间表的 startDate
和 endDate
,如果是有多个时间计划表,则一定是需要包含所有的时间段,否则会报错:
1 | { |
最后,baseTerritory
基准国家对应的价格点是必须设置,否则会报错:
1 | { |
最后,还有一个注意事件,我们这个例子中,基准国家中国大陆(CHN
)从现在到 2023-04-25
使用的 CNY¥ 2.50
价格点设置全球均衡价格,从 2023-04-25
开始,使用 CNY¥ 1.00
价格点设置全球均衡价格。例外的是中国香港,从现在开始一直是手动调整 自定价格
HKD $16.00
。但在苹果 ASC 后台展示的价格时间表:
只有 22 个国家或地区,会跟随 2023-04-25
进行自动调整。剩下的 152 个国家或地区,因为基准国家的 CNY¥ 1.00
和 CNY¥ 2.50
对应的全球均衡价格都是相同的价格点,所以并不会随 2023-04-25
进行自动调整。这个需要注意,后续的苹果调价计划,还有外汇汇率或税率调整等因素的影响。
综上总结,设定某个 IAP 的价格调整(IAP 级别)的接口,必须遵循的规则:
baseTerritory
基准国家startDate
或 endDate
,或者都为空时的全时间段。1 | GET https://api.appstoreconnect.apple.com/v1/apps/{id}/appAvailability?include=app,availableTerritories |
响应示例:
1 | { |
1 | GET https://api.appstoreconnect.apple.com/v1/appAvailabilities/{id}?include=app,availableTerritories |
接口响应与上一个接口一样,具体作用是否一样,暂时未发现区别。
1 | GET https://api.appstoreconnect.apple.com/v1/appAvailabilities/{id}/availableTerritories |
响应示例:
1 | { |
1 | POST https://api.appstoreconnect.apple.com/v1/appAvailabilities |
请求体:
1 | { |
这个请求比较简单,把需要销售的国家或地区放到 availableTerritories
下的 data
数组中就可以,不在 data
数组里的国家或地区,就是表示不支持的地区。测试发现,请求成功后,ASC 后台马上生效。
1 | GET https://api.appstoreconnect.apple.com/v1/inAppPurchaseAvailabilities/{id}/availableTerritories |
响应体:
1 |
|
1 | GET https://api.appstoreconnect.apple.com/v1/inAppPurchaseAvailabilities/{id}?include=availableTerritories |
响应体:
1 | { |
1 | POST https://api.appstoreconnect.apple.com/v1/inAppPurchaseAvailabilities |
1 | { |
这个请求比较简单,把需要销售的国家或地区放到 availableTerritories
下的 data
数组中就可以,不在 data
数组里的国家或地区,就是表示不支持的地区。测试发现,请求成功后,ASC 后台马上生效。
1 | GET https://api.appstoreconnect.apple.com/v1/subscriptionAvailabilities/{id}/availableTerritories |
1 | GET https://api.appstoreconnect.apple.com/v1/subscriptionAvailabilities/{id}?include=availableTerritories,subscription |
1 | POST https://api.appstoreconnect.apple.com/v1/subscriptionAvailabilities |
响应体:
1 | { |
文中的请求示例是精简后的内容,详细的请求示例(Python 代码实现)和请求响应内容,我们放在 GitHub 仓库 37iOS/AppStoreConnectAPI-Demo,后续 API 升级都会一起更新,大家可以自行获取。
关于 API 请求,需要考虑好分页的可能性,未来可能超过 175 个国家地区时的就需要分页,而对于全球均衡价格和自定价格等时间表,有可能超出 200 个价格时间表,所以肯定是需要考虑好分页处理。另外,我们近期会更新苹果派 AppleParty 以支持批量配置苹果新价格机制,敬请期待~
最后,苹果 App Store Connect API 文档的介绍依然有待提高,了解一个 API 的参数变化,都要重复几百次测试。最后,让我们一起期待 2023 年 6 月苹果 WWDC23 带来更多变化吧~
欢迎大家评论区一起讨论交流~
欢迎关注我们,了解更多 iOS 和 Apple 的动态~
]]>注:如若转载,请注明来源。
本文首发于 App Store 新定价机制 - 2023年最全版 - 掘金,欢迎关注我们 @37手游iOS技术运营团队 。
作者:iHTCboy
本文介绍了苹果 App Store 的新定价机制,是 App Store 在 15 周年之际推出的最重要价格升级。
文章通过“为什么,是什么,怎么办”的方法论,让读者从根本原理上理解新机制的意义、背后的原因以及应对方式。对苹果 App Store 新定价机制最全面和最详尽的解读,相信会让关注的苹果开发者能快速了解,因此本文力求让开发者们从容应对新的价格系统,并掌握 App Store 新定价机制。
大家好!我们在上一篇文章 《关于 App Store 苹果商店价格的那些事(历上最全版)》 介绍了苹果 App Store 价格的历史,2023 年 3 月 9 日苹果正式上线新的 App Store 的定价机制,有非常多的朋友表示对新机制一知半解,好像懂又好像完全不懂,因为苹果这次升级是完全推翻了之前的价格等级(Price Tier
),颠覆了大家对它的认知,推出新的 “自定义价格”(customer Price
),这正是本文要解答的重要内容之一。
App Store 新定价机制 是苹果 App Store 在 15 周年之际推出的最重要价格升级!我们之前文章已经提及其中一部分的原因,本文我们就一起重新学习!从入门到精通新定价机制的原理,充分了解新机制背后的原因和解决的问题,从而可以轻松应对新的风险和机遇。
注:本文很多内容,是假设读者已经阅读过 《关于 App Store 苹果商店价格的那些事》 的前提下展开编写,所以本文会多次提及前文内容但不会细讲,所以未看过的读者,建议先阅读,再读本文。
本文会从“为什么,是什么,怎么办”的思路编写,让大家知道为什么改变,改变了什么内容,这些内容更新和配置会带来什么影响,开发者怎么适配等等,从而认每位开发者都能全面地掌握 App Store 定价机制。
所以本文就带大家一起深入浅出地学习!如果喜欢本文,记得点个赞呗~
首先,我们先了解一下 App Store 平台的商业模式:
所以,App Store 的价格设置,主要是 2 个维度,App 级别和 IAP 级别。 记得这个级别的区别,后续讨论的配置都是基于这个前提的。
为什么要增加新价格? 或者这样反问:现有价格点不能满足那些需求呢?
跨国差异。举例来说,假设一款应用程序在美国的价格为 $2.99,在印度的价格也是 $2.99,但由于汇率和购买力等因素的影响,在印度,该应用程序的售价可能过高,当地顾客就会觉得太贵,导致销售量下降。有没有办法让不同地区的价格不一样,我们之前文章说过,2014 年苹果在中国大陆推出 备用等级
“1 元区”,正是针对中国大陆的用户习惯,当年大家买一份报纸就是 1 元!
而如今 2023 年,全球那么多国家和地区,如果都单独增加一些特殊价格的 备用等级
,理论上是可行的,但为什么不这样做,可能当年中国区 1 元价格是因为中国市场是巨大的(事实上也证明了),所以其它国家/地区苹果没有动力做?
缺乏灵活性。另一个例子,最近全球汇率波动大,各个国家或地区的税率政策变化频繁,正如我们之前文章说过,仅 2022 年苹果价格调整就有高达 4 次,这么频繁的调价对于一般 App 可能影响没有这么大。但如果是对于量级大的 App 或游戏,因为价格的调整,会导致 App 充值生态、结算和对账混乱等问题,影响的范围会非常的深远!
那么,苹果新定价机制升级了那些内容呢?我们先从 价格点(Price Points)说起,了解旧价格机制,对比新价格机制,然后说明新价格机制的优缺点。
我们之前文章说过,苹果一直以来都是根据 产品定价等级表 来设置付费 App 和 IAP 内购商品的价格,例如:
产品定价等级 | 价格(USD) | 价格(CNY) | 等级说明 |
---|---|---|---|
1 | 0.99 | 6 | 等级 1 |
2 | 1.99 | 12 | 等级 2 |
3 | 2.99 | 18 | 等级 3 |
4 | … | … | … |
5 | … | … | … |
简单来说,如果开发者设定价格为:产品定价等级 1
,则表示价格在 USD(美元)结算的国家或地区,用户支付金额为 0.99 美元,在中国大陆 CNY(人民币)则是 6 元。(注:未考虑税费问题)
苹果这个定价等级关系,同一个定价等级在不同货币之间是一一对应的关系,开发者不能改变映射的价格关系。也就是说,产品定价等级 1
的 USD 0.99 美元价格不能设置 CNY(人民币)为 12 元。也不支持,自定义设置价格,比如产品定价等级上没有的价格,例如 USD 1.68 美元、CNY 4 元、CNY 9 元等等。
扩展知识:为什么美元 USD 不是只有美国才用?因为苹果在 175 个国家和地区的商店,目前只有 45 种货币为产品定价。也就是有 130 个国家或地区使用的是美元(USD)或欧元(EUR)等等同一种货币结算。
综上,苹果旧的 ”价格等级”(Price Tier) 机制,已经不能完全适应如今的市场需求。“自定义价格”(Customer Price) 应运而生!
2023 年 3 月 9 日苹果正式上线新的 App Store 的定价机制,大概更新的内容:
下面,我们就一个一个来讲解。
怎么理解 更为灵活的价格点 ?
从现在开始,我们要摒弃 ”价格等级”(Price Tier)
的理念,从今世间再无价格等级表!
苹果全新的“自定义价格”(customer Price
) 矩阵表:
注:因为价格矩阵表过大,上图只展示部分国家/地区的部分价格点,用于本文参考示例。
扩展知识:苹果针对不支持当地货币的国家或地区,统一使用美元来结算,如上图中的中国澳门MAC(USD)
。
从上图片可以直观看出,使用 自定义价格(customer Price
) 来统称价格点。我们以美国(美元)为基准时,可以得到以下结论:
价格点按价格区间逐渐递增
注:上图价格点区间图表,下载链接 https://www.apple.com.cn/newsroom/pdfs/App-Store-Pricing-Update.pdf 。
价格点区间,规则说明示例:
RMB 0.5
;RMB 10 到 RMB 200 之间每档相差 RMB 1
等。USD$ 0.1
;USD$ 10 到 USD$ 50 之间每档相差 USD$ 0.5
等。注:为什么是
USD$
呢?在$
前增加USD
,是因为$
不只是美元。我们之前在 游戏出海本地化概述 文章中有讨论过:“$” dollar 使用的国家或地区:
- 港币: HongKong dollar
- 台币: New Taiwan dollar
- 新西兰元: New Zealand dollar
- 澳元: Australian Dollar
- 新币(新加坡币): Singapore dollar
- 加元(加拿大元): Canadian dollar
以上这些价格点的区间,大家可以不用记住,大概了解最低和最高价格点,然后在苹果 ASC
(App Store Connect,下文统一简称 ASC) 后台下载 “自定义价格”(customer Price
) 矩阵表,就能查看所有国家或地区的价格点。下载的方法有 2 个:
苹果总计有 900 个价格点,其中在 “自定义价格”(customer Price
) 矩阵表里面有 800
个价格点,从 USD$ 0.29 ~ USD$ 1000(人民币 RMB 1 ~ RMB 7499)。另外 100 个高价价格点可通过 申请 (需要登陆开发者账号)获得。100 个高价格点是从 USD$ 1099.99 ~ USD$ 10000(人民币 RMB 7997 ~ RMB 74999)。
全球均衡价格遵循了各个国家或地区最常见的定价方式。采用全球均衡价格,你可以提供更适用于当地顾客的定价。
那么什么是 全球均衡价格
呢?在 ASC 后台,价格与销售范围(或 App 内购买项目) -> 价格时间表 -> 所有价格和货币,可以打开下面的页面:
我们选择一个国家或地区和价格点后,苹果将根据最新的外汇汇率自动计算所有 175 个国家或地区的价格和收入。
我们在来对比一下 “自定义价格”(customer Price
) 矩阵表,以下,我们以美国 USD$ 0.99 价格点来分析一下:
从上图我们有 2 种颜色,分别是 USD$ 0.99 和 USD$ 1.99,对应的部分国家和地区的全球均衡价格:
USA (USD) | CHN (CNY) | HKG (HKD) | TWN (TWD) | MAC (USD) | JPN (JPY) | KOR (KRW) |
---|---|---|---|---|---|---|
0.99 | 8 | 8 | 30 | 0.89 | 100 | 1100 |
1.99 | 15 | 18 | 60 | 1.99 | 300 | 3300 |
可以看出来,USD$ 0.99
价格点,现在苹果的全球均衡价格系统,认为在中国的价格是人民币 RMB¥8
。(注:如果用以前的价格等级(Price Tier)是 CNY¥6,JPY¥160)
所以,开发者需要注意!“自定义价格”(customer Price
) 矩阵表,不再是一一对应关系,列表上的不同国家或地区,可以映射为价格相差很大的不同价格点! 那么怎么配置不同的价格点映射,下文会讲到,这里先跳过。
所以,现在明白苹果说的以下 2 点内容了吧:
针对付费 App 和一次性 App 内购买项目,指定你熟悉的国家或地区,以之为基础为其他 174 个国家或地区的店面以及 43 种货币生成全球均衡价格。你为这个基准店面设定的价格,Apple 不会根据税款或外汇变化进行调整。此外,你也可以按个人喜好为每个店面自行设定价格。
怎么理解 基准店面设定的价格 呢?
我们以前配置 App Store 价格,是以价格等级(Price Tier) 美元为基准。很简单就可以明白,那现在我们怎么选择国家/地区和货币为基准呢?
答案就是:根据我们上面介绍的 “自定义价格”(customer Price
) 矩阵表和全球均衡价格系统。苹果现在允许我们选择 3 种定价方案策略:
3.3.1 全球价格调整
简单来说,就是苹果根据全球均衡价格系统,自动帮你调整不同国家或地区的更适用于当地顾客的定价,你不用操心!?
那么,怎么做到苹果自动调整定价呢,就要开发者设定一个基准国家或地区
。比如设置:
RMB¥8
那么苹果的全球均衡价格系统,就会计算剩下的其他 174 个国家或地区的店面以及 43 种货币生成全球均衡价格。
这就是自动定价~ 但需要注意,此时,中国大陆作为基准,所以中国大陆的价格,并不会随着全球汇率的变化而价格调整,因为,其它 174 个国家或地区的价格,要通过中国大陆的价格来计算汇率和价格从而自动调整,明白了吧?
3.3.2 自定价格调整
就是你可以自由的不同国家或地区的价格点:
自定价格,可以理解为“固定”价格,相当于开发者写死的价格,它不会跟进汇率和全球均衡价格系统的价格调整。
3.3.3 临时价格调整
如促销或汇率变化等原因,开发者可以选择一段时间的一些国家或地区的价格调整,调整的方法为 自定价格调整。
以上就是 基准国家或地区
的作用!
针对不同国家和地区的店面决定 App 内购买项目 (包括订阅) 的销售范围,因此你可以为各个市场分发定制的内容和服务。
以前,苹果 IAP 购买并不能限制购买的用户所在的国家或地区,IAP 配置只有一个勾选或不勾选“准许销售”,用来决定内购商品是可以购买或不能购买。
现在苹果允许开发者选择 IAP 上架的国家或地区:
没有勾选的国家或地区所在地的苹果账号,不能购买此 IAP 商店。(注:具体的规则和效果,下文会单独讲解。)
苹果建议:
如果你计划更改 App 内购买项目的销售范围,请考虑用户可能会受到的影响,以及如何妥善地通知用户。
为确保用户体验,建议你先完成以下准备工作,再下架 App 内购买项目:
详细参考:为 App 内购买项目设置销售范围
以上,就是苹果 App Store 的新定价机制的全部内容!你理解了吗,给一个点赞吧~
新的 App Store 的定价机制的优点:
缺点/不足:
注意!现在开发者,就可以针对已经上架或者准备上架的 App 设置价格,选择基准国家或地区或销售国家/地区等。
前面,我们提到,配置价格,有2个级别:
而定价方案,开发者可以选择 2 个价格配置:
下面,我们将从 3 个维度,分析不同场景下的配置区别:
如果开发者现在已上架的 App 什么都不处理,到 2023 年 5 月 9 日,现有 App 和一次性 App 内购买项目还没有完成价格更新,那么苹果 将以产品当前在美国店面的价格为基础,为它们生成相应的更新价格。
简单来说,就是以美国(美元)为基准国家或地区,根据以前的价格等级(Price Tier)的美元价格,通过全球均衡价格系统,分别设置不同的国家或地区的价格。
如果开发者修改了 App 级别的 “基准国家或地区”,那么未设置 IAP 基准国家或地区会继承使用 App 级别的基准国家或地区
App 级别的 “基准国家或地区”,是指 ASC 的 App 下面的 价格与销售范围
标签下配置。
那么这个 App 下的所有未设置 IAP 基准国家或地区的内购买商品(IAP),都将以 App 级别的基准国家或地区,来自动计算不同国家或地区的全球价格。
举例来说:
USD $0.99
,对应人民币 CNY ¥6
中国
;IAP 级别(未选择)以上的 IAP 商品,当 App 级别的基准国家或地区设置为中国大陆
时,IAP 的价格不会马上进行调整。
当有新的价格平衡生效(全球均衡价格系统价格调整),例如目前苹果确认 2023 年 5 月 9 日会生效!
根据目前苹果全球均衡价格矩阵表,可以查到以中国大陆基准国家或地区 CNY ¥6
最新的价格矩阵:
注:“全球均衡价格矩阵表”可参考 3.2 全球定价机制章节
所以,2023 年 5 月 9 日(新的价格平衡生效),这个 IAP 商品在美国还是 USD $0.99
,但日本从等级价格(Tier 1 )原来的 JPY ¥160
,变成全球均衡价格系统给出的 JPY ¥100
。其它的国家或地区类似推导。
简单来说,要先设置 IAP 商品的基准国家或地区。然后决定是否要使用全球均衡价格。否则,苹果默认使用全球均衡价格系统,自动算各国家地区的价格,新价格可能会比原价格高,或者低,所以开发者需要自行检查和决定。大家明白这个意思了吧?
如果开发者设置了 IAP 内购买的基准国家或地区,则 IAP 内购买会以当前 IAP 的基准国家或地区为准。并且如果选择全球均衡价格时,各国家地区的价格,会马上生效!!!
举例来说:
USD $0.99
,对应人民币 CNY ¥6
中国
根据目前苹果全球均衡价格矩阵表,可以查到以中国大陆基准国家或地区 CNY ¥6
最新的价格矩阵:
注:“全球均衡价格矩阵表”可参考 3.2 全球定价机制章节
注意此时此刻,这个 IAP 商品的各国家和地区的价格会马上生效! 如在美国还是 USD $0.99
,但日本从等级价格(Tier 1 )原来的 JPY ¥160
,变成全球均衡价格系统给出的 JPY ¥100
。其它的国家或地区类似推导。
简单来说,目前苹果的全球均衡价格系统已经可用啦!开发者设置 全球价格调整
,则价格会根据全球均衡价格马上调整并生效!
所以,关于基准国家或地区的生效规则 总结:
目前 ASC 后台最新支持配置的销售范围,有 2 个级别:
4.5.1 App 级别的销售范围
4.5.2 IAP 内购买项目的销售范围
IAP 内购商品的销售范围
是新增的配置项以上讲到的配置,如果是全球发行的 App,那么在 ASC 后台人工一个个配置会非常繁琐,所以可以通过 App Store Connect API 进行配置:
App Store Connect API version 2.3 支持以上新价格机制功能的自动化配置,另外可以下载 OpenAPI 规范文档 了解接口的参数和格式要求等。
注:我们后续会单独写一篇文章来说明新 API 的使用示例,敬请期待和关注我们~
答:目前苹果最新的调整时间为 2023 年 5 月 9 日。后续可能是每个季度调整一次,需要注意的是,不是每个国家或地区都会有价格调整,苹果会定期在各地区根据税款和外币汇率变化更新定价,会根据金融数据机构提供的公开汇率信息更新定价,确保 App 内购买内容的定价在所有商店中保持平衡。
App Store 的全球平衡工具将为开发者提供简单便利的方式,在国际市场中管理定价。当然,开发者可随时根据税款和外币汇率的变化自行调整定价。
苹果在去年 2022 年 5 月 16 日的 订阅通知更新 公告中说明:当自动续期订阅提价时,订阅者必须在 App 提价之前选择接受。
。
所以,根据苹果全球均衡价格系统,如果自动调整价格是涨价会怎么样呢?
【2023-04-21】更新
之前的回答有错误,苹果的新价格机制,不会影响到自动续期订阅产品! 管理自动续期订阅的定价:
汇率变化和税务调整会如何影响自动续期订阅的价格?
Apple 不会对你的自动续期订阅产品进行价格调整。Apple 可能会针对税务变化和重大汇率变动调整零售价格,但价格调整不涉及自动续期订阅。请注意,由于你的收益和 Apple 的佣金均在扣除增值税(VAT)之后计算,因此 VAT 税率变化会影响你的收益。你可以选择调整你的订阅价格,以减少税务或外汇变化对你的收益造成影响。
所以,关于自动续期订阅产品不会使用全球均衡价格系统,也不会自动涨价。而提高自动续期订阅价格,全权由开发者决定,需要订阅者同意的情况:
详细参考官方文档:管理自动续期订阅的定价
新创建的 App 或 IAP 内购买项目,苹果默认都没有配置销售范围和价格时间表,需要开发者按最新的定价规则进行配置:
如果苹果后台配置了限制地区,当限制地区的用户点击 App 内购买项目支付时,苹果 StoreKit 会有相应的异常错误,表示用户当前账号地区不在销售范围内。
笔者使用线上 App 的 IAP 项目测试,结果如下:
不能购买
可以发起支付
不能购买
可以发起支付
所以,一句话总结,IAP 项目不在销售的地区,该地区的苹果账号无法完成购买支付!
苹果 StoreKit 会有相应的异常错误,会在 2 个支付环节报错:
SKProductsResponse
中有一个 invalidProductIdentifiers 属性,当数组有值时,里面包含的 IAP 项目就是不在当前用户登陆的 App Store 商店账号的国家或地区销售的 IAP 项目。SKPaymentTransaction
中有一个属性 SKPaymentTransactionState ,当状态为 .failed 时,从 error 属性会有一个 "不提供此项目。"
错误异常。以下是 SKPaymentTransactionState
报错内容的示例:
1 | print("paymentQueue: error: \(transaction.error)"); |
中文环境:
1 | <SKPaymentQueue: 0x2824b0250>: Payment completed with error: Error Domain=ASDServerErrorDomain Code=3502 "不提供此项目。" UserInfo={storefront-country-code=CHN, client-environment-type=Sandbox, AMSServerErrorCode=3502, NSLocalizedDescription=不提供此项目。} |
日文环境:
1 | <SKPaymentQueue: 0x2809d5d30>: Payment completed with error: Error Domain=ASDServerErrorDomain Code=3504 "このアイテムは見つかりませんでした。" UserInfo={storefront-country-code=JPN, client-environment-type=Production, AMSServerErrorCode=3504, NSLocalizedDescription=このアイテムは見つかりませんでした。} |
为什么会在 2 个支付环节报错呢?
因为这样才能保证不会存在支付漏洞,很多开发者或非法用户,可能跳过 productsRequest(_:didReceive:) 方法查询当前 IAP 项目是否在用户地区销售,但如果开始时,用户登陆了 AppStore 账号,而且是销售的地区时,是可以查询到商品的信息,苹果不会回调 invalidProductIdentifiers
,所以当用户支付前,苹果系统还会验证一次最终用户登陆的账号是否在销售地区里,判断逻辑是在苹果服务器,保证判断无误。
另外,苹果这次是调整价格机制,对于 StoreKit Original API 还是 StoreKit 2,字段和收据都没有变化!使用的字段都是以前就存在。另外,StoreKit 2 products(for:) 大家可以自行测试,原理类似通过 StoreKitError 和 Product.PurchaseError.productUnavailable 获取异常错误。
答:目前测试发现大概 30 分钟
左右生效。(线上和测试环境)
答:汇率差解决了,但开发者需要注意价格漏洞!
因为,现在开发者可以设置不同国家或地区的价格,如果你的 App 是全球销售,并且你设置的不同国家的价格点有很大的差异,比如 USD $9.99,而 CNY ¥6,那么必然用户或黑产,会大部使用中国大陆地区进行购买。
这里需要注意,黑产囤货,比如内购收据会大批量保留不消耗,然后销售给用户的问题。
所以,现在开发者设置不同国家或地区的价格点,需要考虑清楚销售的国家或地区,还有销售的价格。
通过 StoreKit 查询到的商品本地化信息是否可靠?比如用户登陆的 App Store 账号登出,购买 IAP 时,系统会要求用户重新登陆账号,此时前后账号的国家地区不一样,就会导致查询到的货币不一样。
答:虽然苹果发布了新的价格机制,并且推出苹果全球均衡价格系统,本质就是计算各国的汇率换算,但是目前为止,苹果依然没有提供汇率换算的 API,当然也包含当前购买的本地化货币。所以,目前并没有 100% 可靠方案。
2023 年 3 月 9 日发布,到 2023 年 5 月 9 日新的价格平衡生效,苹果提供了 2 个月的过渡期。所以建议开发者:
如果在这 2 个月内,开发者什么都不设置,那么过渡期间现在的所有国家和地区的价格不会变化。直到 5 月 9 日新的价格平衡生效,苹果会自动设置基准国家或地区为“美国”,并使用全球均衡价格调整各个国家和地区的价格点。
所以,在这段过渡期,开发者需要思考如何配置适合的价格点,从而提高你的 App 的销售和用户满意度,进一步推动业务增长。
从本文读者们可以看出来,App Store 定价机制涉及面非常广!本文只是从整体上让大家掌握原理,不可能面面具到详细介绍。所以,还有一些细节或疑问,欢迎大家在评论区一起交流~
App Store 问世以来,凭借领先的交易和支付机制,帮助开发者便捷地在全球范围内为其产品和服务进行定价与销售。从为用户提供顺畅结算和明晰收据到强大的营销工具、税务与防欺诈服务以及退款管理,App Store 的交易和支付机制为开发者提供了不断拓展的功能和工具,帮助他们发展业务。
如今新的价格机制,相信开发者现在可以应对自如啦!让我们提升用户的付费体验吧!
欢迎大家评论区一起讨论交流~
欢迎关注我们,了解更多 iOS 和 Apple 的动态~
本文使用 ChatGPT 、New bing 和 NotionAI 参与创作! 如果内容有抄摘或复制,反馈则删除。感谢大家的阅读~
]]>注:如若转载,请注明来源。
本文首发于 关于 App Store 苹果商店价格的那些事(历上最全版) - 掘金,欢迎关注我们 @37手游iOS技术运营团队 。
作者:iHTCboy
苹果 2022 年 12 月 6 日宣布 App Store 定价机制最重大升级,新增 700 个价格点。小编当时的总结和分析:
App Store 新价格:
自动续期订阅商品可以选择 $0.29 美元价格:
自动续期订阅商品可使用 “本地区定价” 和 “自动定价”:
待苹果公布细则~
)待苹果公布细则~
)这次的 定价功能升级 可以说影响非常的深远!为什么这么说呢?所以,这就是本文章跟大家一起探讨的内容,咱们一起来看看苹果商店价格的那些事~
讲到 App Store 的故事,有必要先说说,iTunes Store
的故事。
当然,开始前我们先来看看 Apple Store
,大家可能没有留意苹果商店
的存在,注意是 Apple
!苹果商店是苹果销售自家产品的商店,以前主要是销售 Mac 电脑和 Mac OSX 系统软件(收费),苹果有单独的 Apple Store app 提供。
Mac OS X系统(现在称为 macOS )在最初发布时是需要付费购买的,在 2013 年苹果公司宣布将在未来免费提供系统更新。从那时起,Mac OS X系统的更新版本(如 OS X Mavericks、OS X Yosemite、OS X El Capitan等)都可以免费下载和安装。
从 2015 年开始,苹果公司正式宣布将 Mac OS X 系统更名为 macOS,并继续提供免费更新,包括 macOS Sierra、macOS High Sierra、macOS Mojave、macOS Catalina、macOS Big Sur 和最新的 macOS Monterey。这些更新版本可以在 Mac App Store 上免费下载和安装。
下图是 2000 年时苹果官网 Apple Store 页面,来自 web.archive.org:
iTunes Store 最开始名字是叫 iTunes Music Store
,是第一个成功的数字音乐商店,它在数字音乐领域推动了重要的变革,将消费者从传统的实体唱片店转向了在线购买和下载数字音乐的新模式。
2000 年初市面上已经出现很多 CD 音乐播放器,但是大多数都很差,播放歌曲也少得可怜,待机时间短。从网络下载音乐再刻录光盘的习惯,乔布斯觉得刻录太麻烦,他开始构思透过 iTunes 软件和 iPod 硬件传输歌曲的流程。最终推出 iTunes Music Store,每首歌以 $0.99 美元的价格出售给用户。
有人认为乔布斯了推销 iPod 而建立的网络音乐销售商店,因为除了 iPod 以外,任何其他的便携音乐播放器不能播放在苹果 iTunes 音乐商店上销售的使用 DRM
(Digital rights management,数字版权管理)的音乐文件。
2003 年 4 月 28 日,苹果用 iTunes Music Store 之名开幕,以每首歌 $0.99 美元的价格在线销售音乐文件,在 6 天内就卖掉了 100 万首歌,乔布斯表示“这将作为音乐行业的一个转折点被载入史册”。接着在 2008 年 4 月成为美国最受欢迎的音乐销售商,之后更在 2010 年 2 月成为全世界最受欢迎的音乐商店。
所以不可否认的事实,iTunes Music Store 使得通过网络购买有版权音乐文件的机制变得更便利。所以,乔布斯在2002年被授予格莱美(Grammy)特别成就奖,以表彰他在数字音乐领域的贡献和领导作用。
乔布斯长期以来一直坚持认为,iTunes 音乐商店每首歌 $0.99 美元的价格点应该保持不变,而唱片公司则主张更灵活的价格,新歌的价格更高,常规歌曲的售价更低。
2009 年 4 月开始,苹果宣布 iTunes Store 价格调整,iTunes 上的歌曲将以三个价格点提供:
iTunes Store、Google Music、Amazon MP3 和唱片公司的分成比例都是 3:7
。
2009 年 4 月 7 日,iTunes Store 和 Amazon MP3 的前 10 名单曲价格:
2015 年 9 月 30 日,中国大陆也开放了 iTune Store、Apple Music、iBooks Store(现为 Apple Books)。但对于影视、书刊经营权不符合我国大陆地区的法规,所以从 2016 年 4 月开始暂时关闭。从苹果官网可以查看 苹果服务系统状态 :
iTunes Store 曾经是世界上最受欢迎的在线音乐、电视和电影商店。凭借苹果传奇的易用性,先驱性功能,例如 iTunes Movie Rentals、集成的播客支持、iMix 播放列表共享、以更低的价格把以前购买的音轨转变成完整专辑的功能以及与 iPod 和 iPhone 的无缝集成,iTunes Store 成为了 Mac 和 PC 用户在线合法发现、购买和下载音乐及视频的最佳途径。
iTunes U 是 Apple 公司携手诸多顶级学府联合创建,让人们更便利地丰富知识、探索兴趣所在或加深对院校的了解。iTunes U 是 iTunes 在线商店 (www.iTunes.com) 中的一个专门区域,用户可以访问包括哈佛、麻省理工、剑桥、牛津、墨尔本大学和蒙特利尔大学等世界顶级学府提供的学习内容。iTunes U 让任何人都有机会体验大学课程、实验室演示、体育风采、校园导览以及专题讲座。所有 iTunes U 的内容均可免费获得,并可以在 Mac 或 PC 上欣赏,或者直接无线下载至 iPhone、iPod touch 和 iPad。
iTunes Store 最初是为了提供音乐下载和购买服务而创建的,但随着时间的推移,越来越多的数字媒体类型被添加到 iTunes Store 中,例如电影、电视节目、播客等。这使得 iTunes Store 的界面变得越来越复杂,难以处理不同类型的媒体。因此,为了更好地满足消费者需求和提供更好的用户体验:
2022 年 5 月 10 日,随着苹果公司宣布 iPod touch 停产,音乐生生不息,全系列 iPod 均已宣告停产,iTunes Store 不复存在!
2008 年 3 月 6 日,苹果CEO 史蒂夫·乔布斯 公布了 iPhone 软件路线图,正式宣布推出 App Store 应用商店!
苹果 CEO 史蒂夫·乔布斯说:“我们很高兴创建一个充满活力的第三方开发人员社区,该社区可以为 iPhone 和 iPod touch 提供数千个原生应用程序。iPhone 的企业功能与其革命性的多点触控用户界面和先进的软件架构相结合,为移动设备提供了有史以来最好的用户体验和有史以来最先进的软件平台。”
支持在 iTunes 购买、下载和管理 app:
2008 年前,几家大公司控制了整个软件行业。App Store 为所有开发者敞开了一扇门,不论是个人开发者,还是大型工作室,都能充分施展创意,构建高品质的 app 并顺利地交付给全世界不断壮大的用户群。
推出时苹果就已经确认了 3/7 分成的比例,与之前的 iTunes Store 音乐分成一样:
70% of revenues -> developer
(开发者获取70%分成)当时就明确开发者的年费:
$99
$299
2008 年 7 月 10 日,苹果正式开放 App Store,为 iTunes 用户提供了 552 个 iPhone 和 iPod touch 应用下载。
在 AppStore 发布时,Pinch Media 统计了 552 个应用程序,其中 417 个为付费 App,135 个是免费 App。付费 App 的价格从 0.99 美元到 69.99 美元不等,最常见的价格是 0.99 美元(85个)、9.99 美元(82个)和 4.99 美元(62个)。下图汇总了最初上线 iPhone App Store 应用价格分布的条形图:
刚开始时 App Store 允许开发者,选择免费或付费下载 App,开发者定价可以从 0.99 ~ 999.99 美元之间选择。
2009 年,苹果正式推出 app 内购买(IAP
,In-App Purchase
,应用内购买)功能,用户可以先下载 app,随后付费解锁不同等级和功能,让更多人在愿意购买之前体验全新 app。
所以,App Store 价格定制的形式有 2 种:
开发者可以随意定价,所以,App Store 刚刚发布初期,出现了一个著名的事件:“I Am Rich
”(我很富有)!
2008 年 8 月 5 号,开发者 Armin Heinrich 发布了一款叫 “I Am Rich” 的 app,售价为 $999.99 美元!
App 的功能很简单,打开后显示一个巨大发光红宝石!(如上图),潜台词:“我很富有”!点击右下角图标,会显示一段文字:“我有钱,我应得,我很好,健康且成功”。就这样,一千美元!
当时开发者说,有八位好奇的贵族购买了它!六个人来自美国,一个来自德国,一个来自法国!最初批准 App 分发后,苹果后来将其从商店中删除。最后,苹果退回了用户支付的钱。详细参考 原文。
所以,苹果一般只允许 $99.99 的定价,超过的价格一般审核以前会比较困难,一般会被苹果拒绝。当然,这个要看应用的类型,如今苹果价格最高可设 $10,000 美元!(人民币 RMB 74,999 元),如果说以前超过 $99.99 是不可能, 那么现在一定是可能!
2018 年 6 月 7 日 WWDC,苹果宣布开发者工具 iTunes Connect
变更为 App Store Connect
,并且发布移动端 iOS App 版本 App Store Connect。使用新的 App Store Connect app,可以更方便地管理您的 App、查看趋势、回应评论以及回复 Resolution Center 的问题,还可以收到 App 状态变化以及用户评论的提醒。
现在我们来看看最新的苹果定价规则!
App 内购买项目类型
App 内购买项目类型指可供选择的 App 内购买项目的不同类型。
类型 | 标识 | 说明 |
---|---|---|
消耗型 | consumable | 只可使用一次的产品,使用之后即失效,必须再次购买。示例:钓鱼 App 中的鱼食。 |
非消耗型 | non-consumable | 只需购买一次,不会过期或随着使用而减少的产品。示例:游戏 App 的赛道。Apple 可以托管您的非消耗型产品。 |
自动续期订阅 | subscription | 允许用户在固定时间段内购买动态内容的产品。除非用户选择取消,否则此类订阅会自动续期。示例:每月订阅提供流媒体服务的 App。目前支持的订阅周期:一周,一个月,二个月,三个月,六个月,一年。 |
非续期订阅 | non-renewing-subscription | 允许用户购买有时限性服务的产品。此 App 内购买项目的内容可以是静态的。此类订阅不会自动续期。示例:已归档文章目录的年度订阅。 |
产品定价等级表
App 内购买项目选择的价格决定了顾客价格和您的收入。
产品定价等级 | 价格(USD) | 价格(CNY) | 等级说明 |
---|---|---|---|
1 | 0.99 | 6 | 等级 1 |
2 | 1.99 | 12 | 等级 2 |
3 | 2.99 | 18 | 等级 3 |
4 | 3.99 | 25 | 等级 4 |
5 | 4.99 | 30 | 等级 5 |
6 | 5.99 | 40 | 等级 6 |
7 | 6.99 | 45 | 等级 7 |
8 | 7.99 | 50 | 等级 8 |
9 | 8.99 | 60 | 等级 9 |
10 | 9.99 | 68 | 等级 10 |
11 | 10.99 | 73 | 等级 11 |
12 | 11.99 | 78 | 等级 12 |
13 | 12.99 | 88 | 等级 13 |
14 | 13.99 | 93 | 等级 14 |
15 | 14.99 | 98 | 等级 15 |
16 | 15.99 | 108 | 等级 16 |
17 | 16.99 | 113 | 等级 17 |
18 | 17.99 | 118 | 等级 18 |
19 | 18.99 | 123 | 等级 19 |
20 | 19.99 | 128 | 等级 20 |
21 | 20.99 | 138 | 等级 21 |
22 | 21.99 | 148 | 等级 22 |
23 | 22.99 | 153 | 等级 23 |
24 | 23.99 | 158 | 等级 24 |
25 | 24.99 | 163 | 等级 25 |
26 | 25.99 | 168 | 等级 26 |
27 | 26.99 | 178 | 等级 27 |
28 | 27.99 | 188 | 等级 28 |
29 | 28.99 | 193 | 等级 29 |
30 | 29.99 | 198 | 等级 30 |
31 | 30.99 | 208 | 等级 31 |
32 | 31.99 | 218 | 等级 32 |
33 | 32.99 | 223 | 等级 33 |
34 | 33.99 | 228 | 等级 34 |
35 | 34.99 | 233 | 等级 35 |
36 | 35.99 | 238 | 等级 36 |
37 | 36.99 | 243 | 等级 37 |
38 | 37.99 | 248 | 等级 38 |
39 | 38.99 | 253 | 等级 39 |
40 | 39.99 | 258 | 等级 40 |
41 | 40.99 | 263 | 等级 41 |
42 | 41.99 | 268 | 等级 42 |
43 | 42.99 | 273 | 等级 43 |
44 | 43.99 | 278 | 等级 44 |
45 | 44.99 | 283 | 等级 45 |
46 | 45.99 | 288 | 等级 46 |
47 | 46.99 | 298 | 等级 47 |
48 | 47.99 | 308 | 等级 48 |
49 | 48.99 | 318 | 等级 49 |
50 | 49.99 | 328 | 等级 50 |
51 | 54.99 | 348 | 等级 51 |
52 | 59.99 | 388 | 等级 52 |
53 | 64.99 | 418 | 等级 53 |
54 | 69.99 | 448 | 等级 54 |
55 | 74.99 | 488 | 等级 55 |
56 | 79.99 | 518 | 等级 56 |
57 | 84.99 | 548 | 等级 57 |
58 | 89.99 | 588 | 等级 58 |
59 | 94.99 | 618 | 等级 59 |
60 | 99.99 | 648 | 等级 60 |
61 | 109.99 | 698 | 等级 61 |
62 | 119.99 | 798 | 等级 62 |
63 | 124.99 | 818 | 等级 63 |
64 | 129.99 | 848 | 等级 64 |
65 | 139.99 | 898 | 等级 65 |
66 | 149.99 | 998 | 等级 66 |
67 | 159.99 | 1048 | 等级 67 |
68 | 169.99 | 1098 | 等级 68 |
69 | 174.99 | 1148 | 等级 69 |
70 | 179.99 | 1198 | 等级 70 |
71 | 189.99 | 1248 | 等级 71 |
72 | 199.99 | 1298 | 等级 72 |
73 | 209.99 | 1398 | 等级 73 |
74 | 219.99 | 1448 | 等级 74 |
75 | 229.99 | 1498 | 等级 75 |
76 | 239.99 | 1598 | 等级 76 |
77 | 249.99 | 1648 | 等级 77 |
78 | 299.99 | 1998 | 等级 78 |
79 | 349.99 | 2298 | 等级 79 |
80 | 399.99 | 2598 | 等级 80 |
81 | 449.99 | 2998 | 等级 81 |
82 | 499.99 | 3298 | 等级 82 |
83 | 599.99 | 3998 | 等级 83 |
84 | 699.99 | 4498 | 等级 84 |
85 | 799.99 | 4998 | 等级 85 |
86 | 899.99 | 5898 | 等级 86 |
87 | 999.99 | 6498 | 等级 87 |
510 | 0.99 | 1 | 备用等级 A |
530 | 0.99 | 3 | 备用等级 B |
550 | 0.99 | 8 | 备用等级 1 |
560 | 1.99 | 12 | 备用等级 2 |
570 | 2.99 | 18 | 备用等级 3 |
580 | 3.99 | 28 | 备用等级 4 |
590 | 4.99 | 30 | 备用等级 5 |
目前苹果允许开发者选择的定价就是以上 94
个不同价格点!他们对应的不同国家或地区的当地货币,用户支付时,不会跟随汇率变动。所以,当某些国家或地区的汇率变化很大时,就会导致开发者亏损,或者被利用这个汇率差,切换 App Store 到汇率低的地区进行充值。目前为止,苹果还没有同步新的定价机制升级之前,是由苹果不定期更新产品定价等级表,调整某个地区的价格来解决。
另外关于 备用等级
,下文会介绍,这里先略过。
至此,我们已经知道了苹果 App Store 关于定价的基本规则,接下来我们在说说一些更新的规则。
2011 年,App Store 开始支持订阅,但是只适用于某些类别的 App,如音视频流媒体、云数据、报纸书刊订阅等。
新的订阅分成模式
2016 年 6 月 13 日,苹果全球市场营销高级副总裁 菲尔·席勒(Phil Schiller)宣布:
为什么调整订阅模式?订阅模式扩展到所有应用类别,包括游戏。当开发者将订阅模式加入自己的游戏中后,玩家每月定期付费,定期获取游戏装备,当然开发者也可以给订阅用户一些优惠。另一方面,订阅是一个相对固定的收入,用户不取消订阅,说明开发者的 App 有价值!也是苹果支持开发者!支持好内容!与合作伙伴共赢的梦想!
至此,App Store 平台上的商业模式:
在上文中,我们有列出几个特殊的 备用等级
:
产品定价等级 | 价格(USD) | 价格(CNY) | 等级说明 |
---|---|---|---|
510 | 0.99 | 1 | 备用等级 A |
530 | 0.99 | 3 | 备用等级 B |
550 | 0.99 | 8 | 备用等级 1 |
560 | 1.99 | 12 | 备用等级 2 |
570 | 2.99 | 18 | 备用等级 3 |
580 | 3.99 | 28 | 备用等级 4 |
590 | 4.99 | 30 | 备用等级 5 |
这里就不得不提到中国区的 App Store 付款方式的历史!
在中国大陆,2009 年 10 月 1 日,中国联通开始在中国联通网上营业厅预约销售 iPhone 3G 和 3GS 版手机。
直到 2014 年之前,在中国大陆的 App Store 用户只能使用 iTunes 礼品卡或者使用国际信用卡进行购买。对于一般的用户,非常难形成付费习惯,信用卡也不容易申请到。
银联支付:
银联支付
选项。银联卡支付,它指的是银联网络所发行的借记卡或者信用卡都可以进行支付。在中国,银联卡是非常常见的支付方式,因此苹果公司决定在中国地区添加银联卡支付选项,以便更好地满足中国消费者的需求。
苹果在中国开起 “1元店”
一周后,2014 年 11 月 24 日,苹果在中国的 App Store 应用商店将一些应用的价格降至了 1 元或 3 元。随后苹果公司宣布,1 元及 3 元将成为中国区应用商店新的价格标准。
从银联支付,到加上这一次的降低价格门槛,让 App Store 变得非常亲民!这些做法都有助于中国的用户养成购买正版应用的习惯。
支付宝支付:
支付宝支付
选项。微信支付:
微信支付
选项。目前为止,中国大陆可与 Apple ID 搭配使用的付款方式:
2020 年 11 月 18 日,苹果公布 App Store Small Business Program 计划:
App Store 小型企业计划日历年收入在 100 万美元以下的小型和独立开发者将可以享受 15% 的佣金费率,仅为 App Store 标准佣金费率 30% 的一半,更多细节阅读 App Store 小型企业计划 。
In App Purchase 这几年重要的更新或调整,可能参考之前的梳理:WWDC22 - In App Purchase 更新总结。
最后,开发者从 App Store 收到的收入分成,是怎么处理的?
苹果一般以 5 周(每年 1/4/7/10 月)或 4 周(其余的月份) 作为一个结算周期,并在每个结算周期结束后第 33 天内向开发者付账,40 天内开发者银行收到款项(如收不到,联系苹果)。
苹果 2023 AppStore 账单日历:
需要指出的是,2022 年 12 月有 5 周!关于为什么这一年的 12 月会有 5 周,还有更多苹果 App Store 的财年和账单周期的问题,都可以参考我们之前的文章 苹果 App Store 财年和账单那些趣事,里面已经全部为大家解答~
关于 App Store 可以选择的价格点和规则,我们已经聊的差不多了,接下来,我们聊一点点技术问题!在实践应用过程中遇到的问题!App Store 覆盖 40 多种语言和 175 个地区,开发者如果在不同的地区,显示不同的价格呢?
答:理论上不能,但可曲线救国。直接下载会提示 “App不可用,目前你所在国家或地区尚不提供此App。”,所以,可以把美国账号的国家地区,切换成中国内地,再下载 App。
答:理论上不能,但可曲线救国。通过 3.1 方法下载 App 后,把下载 App 的账号更改为美国地区,然后就可以用美国账号(货币)进行充值。
原因:苹果是为了解决用户移民去了另一个国家或地区,导致之前购买的服务无效的问题,所以没有限制内购的账号。
3.2 中苹果文档有提到:如果出于特定原因需要限制访问权限,请在 App 内部开发解决方案
。
所以,App 内部开发解决方案如何解决限制购买地区的问题?
答:识别用户当前的国家或地区,大概有以下四种方法:
通过苹果商品本地化信息API,可以获取当前苹果玩家登陆的账号,所在的地区和货币类型
。
答:用 SKProduct API 来获取商品的 price 和 priceLocale 参数。然后使用数字格式器来格式化价格,如以下示例代码所示:
1 | let productId = product.productIdentifier |
同国家或地区的商品本地化价格信息,以 0.99 美元商品示例:
地区 | 本地化价格 | 价格 | 货币符号 | 货币代码 | 国家地区码 |
---|---|---|---|---|---|
中国 | ¥6.00 | 6 | ¥ | CNY | CN |
美国 | $0.99 | 0.99 | $ | USD | US |
韩国 | ₩1,500 | 1500 | ₩ | KRW | KR |
中国香港 | HK$8.00 | 8 | HK$ | HKD | HK |
中国台湾 | $33.00 | 33 | $ | TWD | TW |
中国澳门 | US$0.99 | 0.99 | US$ | USD | MO |
日本 | ¥160 | 160 | ¥ | JPY | JP |
乌克兰 | 0,99 US$ | 0.99 | US$ | USD | UA |
此 API 缺点:
具体支持的货币类型和国家和地区,在苹果后台的内购商品价格,点击“其它货币”可以查看:
iOS 13+ 以上系统,苹果提供新的 SKStorefront API
接口,可以直接获取当前 AppStore 商店登陆的账号所在的地区(就是用户的 Apple ID 绑定的国家或地区),这个更加能真实的反映当前用户的账号所有的地区。
比如澳门,是只支持美元支付,返回的货币类型是美元,但是返回的商店地区一定是澳门,所以,更加能达到精确用户的目的,并且是实现的同步接口,不用消耗时间。所以,在 iOS13 以上,默认是返回商店账号所在的国家或地区。
iOS 13 以上使用商店账号所在的国家或地区代码,示例:
API 优点:
最后一个问题,就是开发者都会关注的,就是完成购买后,用户真实支付的货币类型是什么呢?
答:目前从苹果 StoreKit API、App Store Connect 后台的交易趋势或账单,或者是苹果开发者文档,都没有找到相关的资料!!!
最终支付什么币种,应该由苹果通知给金流商户,但金流商户最终用什么币种,是否一定遵守商家,不得而知。所以 App Store 不同国家或地区,支持的货币,而用户最终支付的币种,以结算的金融机构为准。
所以,通过以上 API 可知,目前在用户支付阶段,暂时没有 API 或技术方法,可以获取到用户真实支付的货币种类。只能是通过限制国家或地区码,或者相信苹果接口返回的商品货币种类来判断。
如果读者们了解其它方法,或者有更多补充,欢迎评论区一起交流~
2022 年起,随着全球经济的黑天鹅事件变化,汇率波动变得越来越频繁,苹果的产品定价等级价格调整,也越发频繁,对开发者的影响也越来越大!
单 2022 年苹果价格调整就有四次:
其中,最近的二次我们做了监控,发现了一些问题~
2022 年 9 月 19 日苹果同步的调价公告中:
最早于 2022 年 10 月 5 日起,下列地区 App Store 上的 App 及 App 内购买项目 (自动续期订阅除外) 价格将有所提高:智利、埃及、日本、马来西亚、巴基斯坦、波兰、韩国、瑞典、越南和所有使用欧元货币的地区。
正好是国庆期间,没错!苹果不放假!
我们根据苹果的 StoreKit API、App Store Connect API,做了一个价格变化的监控告警:
我们在 2022 年 10 月 6 日 7:49 分收到了日本地区的价格调整更新通知,9:24 收到韩国地区更新通知。
我们本以为线上更新已经生效!结果,并没有!沙盒环境的价格,测试发现是新价格,但商店下载的线上环境,价格还是旧价格!!!刚开始我们以为苹果更新没有全部生效,结果等了连续好几天~ 最为怪诡的事件,还不止这一件!
我们发现已经更新到新价格的设备,突然充值时又显示旧的价格了!oh my God~
后来,我们学聪明了,在 App 里监控最新的价格,这样就可以分析到真实线上的价格变动!结果也证明了以上2件事真实存在并且又发生了!
2023 年 1 月 27 日苹果价格调整:
2023 年 2 月 13 日起,哥伦比亚、埃及、匈牙利、尼日利亚、挪威、南非和英国 App Store 的 App 及 App 内购买项目 (自动续期订阅除外) 的价格将上调。
结果,我们在 2023 年 2 月 14 日 16:37 分收到了英国地区的价格调整更新通知,这次我们监控的是线上用户的价格变更:
这个就是价格波动的证据,0.99 变成 0.89:
从 2008 年苹果 iPhone 3G 和 App Store 推出,到如今 App Store 已经是世界最大的软件商店!
2018 年 App Store 10 周年之际,苹果全球市场营销高级副总裁 Phil Schiller 表示:“在 App Store 的第一个 10 年,它已经超越了我们所有大胆的设想,我们看到了开发者天马行空的 app 设计,也看到了这些 app 如何成为用户生活中密不可分的一部分,然而这只不过是个开始。开发者的创作令我们感到无比自豪,而未来 10 年 App Store 又将如何发展更令我们无比期待。”
App Store 完全改变了全球人类获取、购买软件和服务的方式。如今,又因为价格,困扰着开发者和用户,虽然目前可能达到一个其它平台无法超越的高度,但远远没有超出人们的想象,每年依然有无数的在未知的空间尽情发挥创造力的 App 诞生!
关于苹果 App 和 App 内购买项目的定价功能升级,在最近 2023 年 1 月 27 日的 App 和 App 内购买项目即将实行税率和价格调整 中宣布一样,从 2023 年春季起:
最近也发现,沙盒环境下,应用内购买的部分价格存在错误,比如 ¥30 元,显示成了 ¥29.90:
应该是苹果调整新的的定价功能导致的,大家可以先忽视~
春季不远了,小编会第一时间更新同步,最新的定价功能升级详细!敬请期待~
欢迎大家评论区一起讨论交流~
欢迎关注我们,了解更多 iOS 和 Apple 的动态~
本文章一起参与编写的同事,还有 ChatGPT 和 NotionAI ! 它们非常的优秀,给文章提供了非常多的思路和大纲,让小编节省了非常多的时间,特别是查找资料校对的时间,以往需要花一天时间的梳理,如今就是一瞬间:
如文章的部分内容或时间点有错误,欢迎大家指出,感谢~
]]>注:如若转载,请注明来源。
城外的人想冲进去,城里的人想逃出来。
——— 钱钟书《围城》
]]>2022年,数万技术创作者在稀土掘金碰撞灵感,沉淀分享,共同成长
他们与技术同行与掘金同行,不断创作出高质量的技术文章,分享超前沿的技术实践
正值 2022 年结尾,掘金举办《2022年度创作者打榜》活动,让我们程序员狂欢的同时,其实也让优秀的开发者和团队,出现在大众的视野,出现在闪烁光芒的舞台舞台上!
所以,笔者从掘金的活动页面,梳理了人气创作者榜单,希望大家可以认识到更多优秀的开发者和团队,关注他们的文章和创新!向优秀学习,是让我们变成自己变得优秀的基础。
2021 年的创作者榜单可阅读: 2021掘金年度技术创作者榜单 | iHTCboy’s blog
这里收集了 87 个掘金的技术团队,排名不分先后。(注:数据收集时间截止:2022 年 12 月 31 日中午 12 点前。
)
这里列出了每个团队的大部分的简介,需要说的是,因为每个团队的创建时间不一样,所以文章的阅读数、点赞数、账号等级都不一定很高,大家可以根据自己的兴趣找到关注点啊~
团队图标 | 团队名 | 简介 | 标签 | 公司 | 首篇文章发表日期 | 首篇文章发表距今(天数) | 掘力值 | 掘金等级 |
---|---|---|---|---|---|---|---|---|
37手游iOS技术运营团队 | 分享技术动态、实践和思考!热爱,开放,严谨,担当~ | iOS技术运营团队 | 三七互娱 | 2020-11-08 | 784 | 4902 | 4 | |
政采云技术团队 | 云原生、人工智能、区块链、安全、中间件 | 政采云技术zero团队 | 政采云有限公司 | 2021-09-10 | 478 | 8122 | 5 | |
OpenTiny社区 | 我们是华为云的 OpenTiny 开源社区,会定期为大家分享一些团队内部成员的技术文章或华为云社区优质博文,涉及领域主要涵盖了前端、后台的技术等。 | 华为云出品的企业级设计体系 | 华为云 | 2022-02-22 | 313 | 1076 | 3 | |
QiShare | QiShare是一个移动端技术文章分享平台。 | 奇舞团移动端团队 | 奇舞团 | 2018-07-23 | 1623 | 31464 | 6 | |
高灯科技交易合规前端团队GFE | 高灯科技交易合规前端团队, 隶属于高灯科技(北京)交易合规业务线研发部,是一个富有激情、充满创造力、坚持技术驱动全面成长的团队。 | 高灯科技GFE团队 | 深圳高灯计算机科技有限公司 | 2022-02-15 | 320 | 2647 | 4 | |
DevUI团队 | devui.design | 面向企业中后台的前端开源解决方案 | 前端组件库 | 华为 | 2020-02-27 | 1039 | 22143 | 5 | |
AirtestProject | 网易游戏AirtestProject团队,开源了airtest和poco2个热门的自动化测试框架,拥有完整的自动化测试解决方案,欢迎咨询 | - | @网易,公众号:AirtestProject | 2019-11-14 | 1144 | 5285 | 4 | |
百度Geek说 | 公众号:百度Geek说 | 架构师 | 百度 | 2021-01-15 | 716 | 12992 | 5 | |
IDuxFE | https://github.com/IDuxFE | 前端 | 深信服前端团队 | 2019-10-07 | 1182 | 8679 | 5 | |
融云 | 安全、可靠的全球互联网通信云服务商 | 公众号:融云全球互联网通信云 | - | 2019-05-13 | 1329 | 4903 | 4 | |
Dromara开源社区 | - | - | https://dromara.org | 2021-04-06 | 635 | 2245 | 4 | |
袋鼠云数栈UED团队 | 创造美好的用户体验. http://ued.dtstack.cn/ | 前端开发工程师 | 袋鼠云(杭州玳数科技有限公司) | 2017-01-10 | 2182 | 3408 | 4 | |
华为云开发者联盟 | 生于云,长于云,让开发者成为决定性力量 | - | - | 2020-05-07 | 969 | 73732 | 6 | |
字节跳动技术团队 | 字节跳动的技术实践分享 | - | 字节跳动 | 2018-07-10 | 1636 | 66678 | 6 | |
转转技术团队 | 转转研发中心及业界小伙伴们的技术学习交流平台,定期分享一线的实战经验及业界前沿的技术话题。 关注公众号「转转技术」,各种干货实践,欢迎交流分享~ | 公众号:转转技术 | - | 2017-08-14 | 1966 | 34575 | 6 | |
京东设计中心JDC | Hi!我们是京东的用户体验设计团队 | UX | 京东 | 2016-08-04 | 2341 | 18458 | 5 | |
LigaAI | 做更懂开发者的智能研发协作平台 | - | LigaAI | 2021-03-31 | 641 | 1516 | 3 | |
雪球工程师团队 | 团队使命:不断提升技术实力,保证质量、提高效率、完善组织,进而帮助雪球业务走向成功; 团队愿景:成为让人信赖、受人尊重、令人向往的技术团队。 | - | 雪球财经 | 2021-03-22 | 650 | 4024 | 4 | |
飞书技术 | 长期招聘各路技术爱好者https://future.feishu.cn/recruit | 飞书技术团队 | 字节跳动 | 2019-04-12 | 1360 | 10007 | 5 | |
StoneDB | 企业级一体化实时 HTAP 开源数据库。 | 专业的HTAP数据库架构师团队 | 石原子科技 | 2022-06-26 | 189 | 318 | 3 | |
字节跳动云原生计算 | 构建新一代海量数据计算平台 | - | 北京字节跳动科技有限公司 | 2022-06-15 | 200 | 865 | 3 | |
字节跳动终端技术 | - | - | - | 2021-05-31 | 580 | 6772 | 5 | |
百瓶技术 | 「百瓶」App 技术团队官方账号。 致力于用技术提高人类生产效率 | DRINK FOR FUN! 👉❤️ GitHub | 品酒研究员 | 公众号 - 百瓶技术 | 2021-08-24 | 495 | 6101 | 5 | |
政采云前端团队 | 政采云前端 ZooTeam 团队,不掺水的原创。 团队站点:https://zoo.team | - | 公众号 @ 政采云前端团队 | 2019-08-20 | 1230 | 109355 | 7 | |
字节前端 | 公众号:字节前端ByteFE | - | 北京字节跳动网络技术有限公司 | 2020-09-23 | 830 | 38304 | 6 | |
蚂蚁RichLab前端团队 | 来自蚂蚁消费金融的全能型前端团队~ | 花呗借呗前端团队 | 蚂蚁集团 | 2016-10-12 | 2272 | 17607 | 5 | |
ZEGO即构 | ZEGO即构科技官方账号;全球音视频云服务通信商。 | 音视频云服务通信商 | ZEGO 即构科技 | 2019-09-10 | 1209 | 2591 | 4 | |
青训营官方账号 | 我是青训营官方小助手,一个帮助大家学习成长的机器人~ | 前端开发工程师 | 北京字节跳动网络技术有限公司 | 2022-04-01 | 275 | 14531 | 5 | |
百应前端团队 | - | - | 浙江百应科技有限公司 | 2020-09-02 | 851 | 3182 | 4 | |
MASA技术团队 | MASA技术团队官方账号,我们专注于.NET现代应用开发解决方案 | - | - | 2021-10-26 | 432 | 1241 | 3 | |
NGINX开源社区 | NGINX开源社区是在NGINX官方直接支持下创建的全球第一个服务于普通NGINX用户和开发者的全中文社区 社区秉持着“开放,包容,沟通,贡献“的宗旨,意在为开发者提供一个自由学习、深度交流、互动讨论、自我成长的平台 | - | NGINX开源社区 | 2021-10-14 | 444 | 515 | 3 | |
运维开发故事 | 公众号运维开发故事团队 | 公众号运维开发故事 | - | 2021-01-31 | 700 | 5096 | 4 | |
得物技术 | 公众号@得物技术 | - | - | 2021-01-29 | 702 | 10703 | 5 | |
字节跳动数据平台 | 赋能字节跳动各业务线,降低数据应用的门槛为始,对内支持字节绝大多数业务线,对外发布火山引擎品牌下的数据智能产品,服务行业企业客户。 | - | - | 2022-11-09 | 53 | 1354 | 3 | |
Uniym团队 | - | CEO | 成都联合一鸣科技有限公司 | 2022-12-30 | 2 | 11 | 1 | |
NebulaGraph | 开源分布式图数据库,千亿顶点和万亿边仅毫秒级查询延时 | 图数据库 | 悦数科技 | 2019-07-23 | 1258 | 4611 | 4 | |
火山引擎开发者社区 | - | - | https://www.volcengine.cn/ | 2021-04-01 | 640 | 628 | 3 | |
支付宝体验科技 | 探索极致用户体验与最佳工程实践 | - | 蚂蚁集团 | 2017-12-11 | 1847 | 2557 | 4 | |
阿里云视频云 | 「视频云技术」你最值得关注的音视频技术公众号,每周推送来自阿里云一线的实践技术文章,在这里与音视频领域一流工程师交流切磋。 | 资深算法工程师 | 阿里云 | 2020-11-05 | 787 | 3443 | 4 | |
腾讯云中间件 | 腾讯云中间件团队,负责腾讯微服务平台TSF、API网关、消息队列CMQ/CKafka和Kon | 企业架构的基石 | 鹅厂 | 2020-01-05 | 1092 | 3882 | 4 | |
58技术 | 58官方技术号,58技术创新、分享与交流平台 | - | 58同城 | 2021-10-25 | 433 | 1237 | 3 | |
Android_开发者 | 谷歌中国 Android 开发者官方账号,汇集 Android 开发者相关的最新资讯。欢迎 | - | 2017-10-23 | 1896 | 49916 | 6 | ||
vivo互联网技术 | 分享 vivo 互联网技术干货与沙龙活动,推荐最新行业动态与热门会议。欢迎 | vivo互联网技术 | vivo互联网 | 2019-03-12 | 1391 | 27359 | 5 | |
ShowMeAI | 为AI硬核资料库(cool)而生!公众号/GitHub:ShowMeAI-Hub 主站:www.showmeai.tech | 资深算法专家 | - | 2021-11-18 | 409 | 36828 | 6 | |
网易数帆社区 | 网易数帆社区是网易旗下,由网易实践者社区、网易资深产品技术和运营 | 开发者 | 网易 | 2018-04-04 | 1733 | 9613 | 5 | |
SelectDB | The enterprise-grade cloud-native distribution for Apache Doris. | - | 北京孚莱维斯科技有限公司 | 2022-06-01 | 214 | 948 | 3 | |
前端指北官方 | 为开发者提供实现职业提升、专业进阶和可持续成长。web开发相关技能(Vue,React,nodejs,JS基础,前端性能优化),前端面试题集锦等 | 前端老垃圾 | - | 2019-06-03 | 1308 | 1545 | 3 | |
OneFlow一流科技 | 一流科技OneFlow团队的技术分享账号,专注于深度学习,擅长分布式相关。 ★ OneFlow深度学习框架:github.com/Oneflow-Inc/oneflow ★ OF云平台:oneflow.cloud | 团队 | 一流科技 | 2021-12-13 | 384 | 3781 | 4 | |
京东云开发者 | - | 技术运营 | 京东科技信息技术有限公司 | 2022-09-26 | 97 | 2919 | 4 | |
飞猪前端团队 | 前端技术让旅行更美好 | 公众号 | fliggyfe | 2018-01-21 | 1806 | 13665 | 5 | |
七牛云 | 七牛云——连接数据,重塑价值 | 七牛官方 | 七牛云 | 2016-06-01 | 2405 | 12253 | 5 | |
闲鱼技术 | - | - | 阿里巴巴集团 | 2018-04-26 | 1711 | 28779 | 6 | |
腾讯云原生 | 腾讯云原生,汇聚腾讯云原生技术最新资讯、最佳实践、最真案例和最火活动 | - | - | 2020-05-22 | 954 | 5686 | 5 | |
FinClip | 行业领先的小程序开发容器,即可轻松让小程序在自有 App 中流畅运行 | - | finogeeks | 2019-06-03 | 1308 | 1789 | 3 | |
即构开发者 | 全球云通讯服务商,帮助企业低成本轻松构建音视频服务。 | - | - | 2022-06-01 | 214 | 737 | 3 | |
又拍云 | - | 运维 | 又拍云 | 2017-06-05 | 2036 | 6504 | 5 | |
字节跳动SYSTech | 公众号【字节跳动SYS Tech】,聚焦系统技术领域,分享前沿技术动态、技术创新与实践、行业技术热点分析。 | - | 抖音视界有限公司 | 2022-10-26 | 67 | 332 | 3 | |
JuiceFS | JuiceFS is a distributed POSIX file system built on top of Redis and S3. | - | Juicedata | 2021-09-08 | 480 | 1257 | 3 | |
比心FE | 我们相信在轻松、和谐氛围下,才能激发更多的创造力和积极性 期待你加入我们团队 一起造火箭!! 联系方式: 1711327128@qq.com | 研发 | 比心APP | 2021-08-16 | 503 | 2043 | 4 | |
Exposir | Eternity is the most romantic | 前端工程师 | - | 2021-07-27 | 523 | 67 | 2 | |
暗河长明 | 女切图仔的摆烂历程 | - | - | 2022-05-10 | 236 | 173 | 2 | |
Elasticsearch | Elastic 社区布道师刘晓国 | Elastic 社区首席布道师 | Elastic | 2019-12-16 | 1112 | 9526 | 5 | |
声网 | 声网(NASDAQ:API)成立于2014年,是全球实时互动云服务开创者和引领者。开发者只需简单调用声网API,即可在应用内构建多种实时音视频互动场景。 | - | 声网 | 2016-11-03 | 2250 | 21278 | 5 | |
凹凸实验室 | https://aotu.io/about | 全栈开发工程师 | 京东 | 2016-03-09 | 2489 | 53600 | 6 | |
Apache_APISIX_中文社区 | Github https://github.com/apache/apisix Apache APISIX 是一个动态、实时、高性能的云原生 API 网关,提供了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。 | - | - | 2019-09-05 | 1214 | 2902 | 4 | |
设计稿智能生成代码 | imgcook.com 专注以 Sketch、PSD、静态图片等形式的视觉稿作为输入,通过智能化 | 阿里巴巴 前端委员会智能化小组 | 阿里巴巴 | 2020-01-07 | 1090 | 14113 | 5 | |
京东前端 | - | 全栈工程师 | 京东 | 2021-12-16 | 381 | 3762 | 4 | |
Rainbond开源 | Rainbond云原生应用管理平台。 Rainbond 核心100%开源,使用简单,不需要懂容器和Kubernetes,支持管理多种Kubernetes集群,提供企业级应用的全生命周期管理。 | - | 北京好雨科技有限公司 | 2019-08-26 | 1224 | 1643 | 3 | |
KubeSphere | KubeSphere 是在 Kubernetes 之上构建的以应用为中心的多租户容器平台,提供全 | 开源的容器平台 | KubeSphere | 2019-08-02 | 1248 | 6693 | 5 | |
SEAL安全 | 专注软件供应链安全 | - | SEAL | 2022-06-14 | 201 | 1278 | 3 | |
StreamNative | 打造基于Apache Pulsar的下一代流平台 | - | StreamNative | 2019-06-11 | 1300 | 3967 | 4 | |
亚马逊云开发者 | 亚马逊云开发者社区是专注于人工智能领域,开发者交流与互动的平台。在这里,你可以分享和获取一切有关人工智能的相关技术和前沿知识。 进入亚马逊云科技开发者网站,请锁定 https://dev.amazoncloud.cn | - | 亚马逊云科技 | 2021-06-22 | 558 | 1907 | 4 | |
Flutter社区 | Flutter: 为所有屏幕构建精美应用。Flutter 是 Google 开源的应用开发框架,通过一套代码库,高效构建出精美、原生平台编译的多平台应用。Flutter 官网: flutter.dev 中文开发者网站: flutter.cn | 开发者社区 | - | 2019-12-23 | 1105 | 2842 | 4 | |
SphereEx | 开源 · 程序人生 · 大数据技术 | - | - | 2021-05-14 | 597 | 2104 | 4 | |
Authing | Authing 是国内首款以开发者为中心的全场景身份云产品,集成了所有主流身份认证协议,为企业和开发者提供完善安全的用户认证和访问管理服务。 | - | Authing | 2017-08-07 | 1973 | 5528 | 5 | |
网易云信 | 网易智企是网易旗下一站式企业服务提供商,包含网易易盾、网易云信、网易云商三大业务板块。 | 开发 | 网易智企 | 2018-06-11 | 1665 | 9382 | 5 | |
ShowMeBug技术团队 | 技术评估与在线 Coding 面试平台 ShowMeBug.com | - | 深圳至简天成科技有限公司 | 2021-03-29 | 643 | 905 | 3 | |
爱奇艺技术 | 一行代码,娱乐万亿 | 娱乐码农 | 爱奇艺 | 2020-03-23 | 1014 | 8314 | 5 | |
JEECG官方 | 专注技术开源,打造开源的JAVA快速开发平台—JEECG(获得CSDN专家访谈,ITEYE访谈、连续五年中国最火TOP5、十大优秀开源项目等)、免费微信管家平台—JeeWx 捷微(获得2014年微信开 | CEO | 北京国炬信息技术有限公司 | 2019-08-26 | 1224 | 2576 | 4 | |
dubbogo社区 | 于雨(github @AlexStocks),dubbogo 社区负责人,一个有十年服务端基础架构和中间件研发一线工作经验的程序员,陆续参与和改进过 Redis/Pika/Muduo/dubbo-go/Sentinel-go 等知名项目。 | - | - | 2021-02-09 | 691 | 418 | 3 | |
alexwang | 后端开发 | - | - | 2022-02-23 | 312 | 99 | 2 | |
数栈DTinsight | 数栈是袋鼠云旗下一站式的数据中台PaaS,我们以技术为核心,让我们一起将未来变成现在 | - | - | 2021-03-12 | 660 | 2217 | 4 | |
MobTech开发者 | - | 产品运营 | - | 2019-03-19 | 1384 | 4128 | 4 | |
TiDB社区干货传送门 | TiDB 社区干货传送门是由社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,希望更多的优质内容传播出去可以减少 TiDBer 学习使用 TiDB 的壁垒,降低运维 TiDB、解读 TiDB 的障碍。 https://tidb.net/ | - | - | 2022-03-18 | 289 | 449 | 3 | |
WebInfra | 字节跳动 Web Infra 部门(团队文章发布号) | 前端 | 字节跳动 Web Infra | 2021-02-22 | 678 | 3876 | 4 | |
OceanBase数据库 | OceanBase是蚂蚁金服和阿里巴巴完全自主研发的金融级分布式关系型数据库 | 技术专家 | OceanBase | 2018-06-12 | 1664 | 3556 | 4 | |
个推开发者 | - | 程序员 | 个推 | 2017-06-20 | 2021 | 5316 | 4 |
个人开发者榜单,收集了前 600 名创作者,基本上覆盖了所有活跃的开发者。所以大家可以根据自己的兴趣找到关注点啊~
开发者头像 | 开发者 | 简介 | 标签 | 公司 | 首篇文章发表日期 | 首篇文章发表距今(天数) | 掘力值 | 掘金等级 |
---|---|---|---|---|---|---|---|---|
iHTCboy | Learn something of everything, learn everything of something. | 移动金栈工程师 | 37 | 2020-01-17 | 1080 | 2482 | 4 | |
宫水三叶的刷题日记 | 公众号: 「宫水三叶的刷题日记 」 | Software Engineer | 微软 | 2021-01-31 | 700 | 25697 | 5 | |
若川 | 每周一起学200行左右的源码共读活动,加微信 ruochuan12 参与 | 关注@若川视野,源码共读!加Vx ruochuan12 参与 | - | 2017-07-26 | 1985 | 32336 | 6 | |
Yestodorrow | 前端架构,北航硕士毕业,专八,专注于系统性能和稳定性建设,欢迎各种交流 | 观测云高级技术专家 | 观测云 | 2018-07-30 | 1616 | 9721 | 5 | |
冴羽 | 理想主义者,个人微信:mqyqingfeng ,带你看技术与生活的诗与远方 | 公众号@yayujs | 🏅掘金签约作者 | 2017-04-05 | 2097 | 73317 | 6 | |
HullQin | game.hullqin.cn 公众号「线下聚会游戏」我做了一些联机桌游网页:支持2-10人联机的UNO、2-4人联机的斗地主、2人联机的五子棋。无需下载,点开即玩!叫上朋友,即刻开局!不看广告,不做任务,享受「纯粹」的游戏! | 公众号@线下聚会游戏 | B站@HullQin | - | 2020-11-30 | 762 | 17371 | 5 | |
小满zs | 哔哩哔哩:小满zs | 快递员 | 京东 | 2021-07-29 | 521 | 1146 | 3 | |
扫地盲僧 | 行走在键盘上的钢琴师 | 💥全栈工程师 | 效率工程负责人 | 百亿级独角兽公司 | 2019-03-11 | 1392 | 10427 | 5 | |
苏三说技术 | 维护者目前就职于某知名互联网公司,对jdk、spring、springboot、springcloud、mybatis等开源框架源码有一定研究 | 公众号 | 苏三说技术 | 2020-05-17 | 959 | 21753 | 5 | |
Sunshine_Lin | 一名Rapper,一位历史迷,一位前端菜鸟 | - | 公众号:前端之神 & B站:林三心的挖掘机 | 2020-06-03 | 942 | 115378 | 7 | |
海拥 | 个人微信【wh18363】QQ前端交流群:563210781;关注公众号:“海拥”,回复”资料”,领取我为你精心准备的各类编程资料,另有近百款经典游戏源码等你来取哦~ | 🥇公众号:海拥 | 水系全栈🥈 | - | 2021-04-26 | 615 | 32412 | 6 | |
yechaoa | 热爱开源,喜欢分享,掘金签约作者、CSDN博客专家、infoQ KOL作者、阿里云专家博主、51CTO专家博主、华为云云享专家;现就职于阿里巴巴,研究方向包括但不限于大前端、端基础架构与中间件、性能优化等。 | 🏆掘金签约作者 | 阿里巴巴 | 2020-11-25 | 767 | 6525 | 5 | |
代码诗人_ | 码农/业余诗人 | 前端开荒 | 月弦笙音艺术社 | 2017-11-12 | 1876 | 2854 | 4 | |
法医 | 我是法医,一只治疗系前端码猿🐒,与代码对话,倾听它们心底的呼声,期待着大家的点赞👍与关注➕。 也欢迎大家来前端猎手交流群一起交流技术以及技术之外的一切,[微信:fedFaYi]👫 | 🏆公众号@前端猎手 | - | 2020-06-09 | 936 | 7557 | 5 | |
why技术 | 用匠心敲代码,对每一行代码负责。 | java工程师 | 公众号【why技术】 | 2019-08-27 | 1223 | 33678 | 6 | |
CUGGZ | 微信:CUG-GZ,添加好友一起学习~ | 🏆公众号:前端充电宝 | - | 2020-05-27 | 949 | 111003 | 7 | |
不要秃头啊 | 前端工程化专栏作者 | 专注前端基建,热衷量化投资 | 某行业龙头企业 | 2021-04-12 | 629 | 12251 | 5 | |
秦风0214 | like life | 一个前端 | ****** | 2021-01-26 | 705 | 58 | 2 | |
洛神灬殇 | 本人是个酷爱计算机技术、醉心开发编程、喜爱健身运动、热衷悬疑推理的”极客狂人“。 | 🏆 资深架构师 | 全方位技术攻关 | 2021-04-14 | 627 | 15235 | 5 | |
刘悦的技术博客 | python,ruby,前端 | python讲师 | v3u.cn | 2020-03-25 | 1012 | 7775 | 5 | |
彭旭锐 | Github · AndroidFamily 项目负责人,关注公众号进 Android 面试交流群! | 🏆掘金签约作者 | - | 2019-07-28 | 1253 | 24017 | 5 | |
前端贰货道士 | CV工程师 | 前端攻城狮 | - | 2021-03-10 | 662 | 2463 | 4 | |
岛民小强 | 🐔你干嘛~嗨哟🏀 | PM | !BAT | 2017-08-11 | 1969 | 2794 | 4 | |
园宵 | 主要负责造轮子、修轮子、补胎。擅长修补扭扭车、自行车、三轮车、平板车、手扶拖拉机、量子火箭、二向箔等 | iOS 开发工程师 | 稿定科技 | 2022-08-11 | 143 | 1466 | 3 | |
前端周公子 | 不会写代码的保洁不是一个好厨子~ V: zhoudeyou945 | 公众号/视频号: 前端周公子 | 非著名👨🍳厨师专业学校 | 2018-04-15 | 1722 | 15137 | 5 | |
NewBoy | 虽不年少,艳阳高照 | coder | - | 2021-04-23 | 618 | 5368 | 4 | |
来碗盐焗星球 | 博客地址: https://fieemiracle.github.io/personnal-blog/ | 东华理工大学 | - | 2022-06-30 | 185 | 5758 | 5 | |
杨同学technotes | https://github.com/studeyang | Java工程师 | - | 2020-08-04 | 880 | 1329 | 3 | |
wjl110 | https://wjl110.xyz https://wjl110.cn | 信息安全 | ByteDance | 2022-04-17 | 259 | 876 | 3 | |
掘金最后一个老实人 | - | - | - | 2021-10-06 | 452 | 2704 | 4 | |
Applehope | Just Design & Code | 架构师 | 平安健康 | 2022-08-21 | 133 | 8009 | 5 | |
Swift社区 | 我们希望做一个最专业最权威的 Swift 中文社区,我们希望更多的人学习和使用Swift。我们会分享以 Swift 实战、SwiftUI、Swift 基础为核心的技术干货,欢迎您的关注与支持。 | 公众号@Swift社区 | - | 2017-12-13 | 1845 | 17162 | 5 | |
齐舞647 | 95后,iOS Dev / Gopher,就职于掘金。喜欢研究各类技术。掘金内推链接:https://juejin.cn/post/7172204499094732830 | 工程师 | 掘金 | 2019-12-29 | 1099 | 3200 | 4 | |
Dream_juvenile | 一切靠自身实力! | 前端工程师 | - | 2022-01-05 | 361 | 496 | 3 | |
掘金安东尼 | Stay hungry、Stay foolish,相信技术、传递价值,安东尼陪你度过漫长编程岁月~ | 前端干事 | 5G消息 | 2019-01-22 | 1440 | 74269 | 6 | |
MiyueFE | 日积跬步,以至千里 | 前端 | MoonStudio | 2019-07-01 | 1280 | 7783 | 5 | |
一骑绝尘蛙 | 喜欢研究花里胡哨的css工程师,希望大家发现好的css特效后能找我分享并研究 | 工程师 | 神仙公司 | 2021-08-01 | 518 | 1794 | 3 | |
ClyingDeng | - | 🏅掘金签约作者|前端 | 公众号:今天你敲代码了吗 | 2019-08-28 | 1222 | 7556 | 5 | |
Petterp | Android DevLoper 🏃🏻, csdn博客专家、阿里云专家博主、Github冲浪选手 🏄🏻。全网搜索 Petterp :) | Android Developer | - | 2020-01-15 | 1082 | 4786 | 4 | |
小杜杜 | 总是在边缘上行走,所以容易掉下去 | 🏆掘金签约作者 | 公众号:React高级进阶 | 2020-11-11 | 781 | 22831 | 5 | |
bug菌 | 在csdn、掘金、阿里云、头条等社区总合计6w粉+,对一切技术都感兴趣,重心java方向。喜交友,若合作请公众号私我吧。 | 公众号 | 猿圈奇妙屋 | - | 2021-10-19 | 439 | 6711 | 5 | |
isboyjc | 一个前端 | 公众号 @不正经的前端 | - | 2019-11-16 | 1142 | 25166 | 5 | |
快跑啊小卢_ | 日日有著數 時時百事通 (微信号:WEIJUNFAT) | 公众号 「前端快快跑」 | Apifox | 2021-04-29 | 612 | 27120 | 5 | |
寒月十九 | - | 大三在校生 | 东华理工大学 | 2022-07-04 | 181 | 2944 | 4 | |
前端小蜗 | - | 前端 | - | 2021-12-08 | 389 | 1226 | 3 | |
王中阳Go | 专注Go语言学习经验分享和简历优化指导。 靠敲代码在北京买房的程序员。 | 🏅掘金签约作者 | 程序员升职加薪之旅 | 2021-03-23 | 649 | 23551 | 5 | |
iwhao | - | 前端工程师 | 前端技术战(是战斗的战呦)@公众号 | 2020-06-15 | 930 | 5140 | 4 | |
JAVA旭阳 | 欢迎关注个人公众号 ——JAVA旭阳 | JAVA开发工程师 | - | 2017-12-21 | 1837 | 11557 | 5 | |
季夏廿九 | 干啥啥不行,摸鱼第一名 | 前端切图仔 | 廿九前端营地 | 2020-08-14 | 870 | 2964 | 4 | |
Ethan_Zhou | 上汽、平安 前端工程师 wx: 1032151090 | web 开发 | 上汽集团 | 2019-03-27 | 1376 | 5455 | 4 | |
小阿杰 | 一个爱鼓捣的程序猿,JAVA开发者和爱好者。公众号【Java全栈架构师】维护者,自建微信小程序【软考真题解析】【实用在线工具箱】,欢迎阅读交流。 | 🥇🏆掘金达人 | 公众号:Java全栈架构师 | 2020-10-24 | 799 | 7294 | 5 | |
codercao | 似卷非卷的办公室满级程序员,一个冇得感情的前端工具 | 🏆掘金签约作者 | 止浅 | - | 2018-05-08 | 1699 | 12300 | 5 | |
WinsonWu | - | - | - | 2021-12-30 | 367 | 1981 | 4 | |
𝓼𝓲𝓭𝓲𝓸𝓽 | - | - | - | 2022-09-01 | 122 | 13169 | 5 | |
ArvinC | 爬山、旅游、学习 | 前端开发 | - | 2021-04-10 | 631 | 2919 | 4 | |
Zuo | 为热爱发电。 | 客户端开发 | .. | 2021-03-02 | 670 | 5880 | 5 | |
知否技术 | 多学一点知识,少写一行代码。 | 公众号 | 知否技术 | 2020-12-25 | 737 | 10210 | 5 | |
猪痞恶霸 | 热爱生活,喜欢民谣与美食,喜欢山与海,喜欢骑行到世界的每个地方,喜欢~ | - | 沈阳理工大学琴理工作室 | 2021-09-26 | 462 | 5776 | 5 | |
FuncJin | 一蓑烟雨任平生 | - | - | 2022-05-08 | 238 | 5607 | 5 | |
布鲁斯要蓝调 | 大学三年级前端偶像练习僧 | - | - | 2022-07-04 | 181 | 1731 | 3 | |
磊叔的技术博客 | GitHub:https://github.com/glmapper | 公众号:PeomByte | HM | 2017-08-27 | 1953 | 19873 | 5 | |
优弧 | 关于掘金的任何反馈都可以找我哈!可以加微信:chnyifan 或者 zwcatfly 进作者推荐群 | 管理员| 首席客服君丨运营负责人 | 掘金 | 2018-02-26 | 1770 | 15205 | 5 | |
阿杆 | 19级在读,主修软件工程 | Java研发工程师 | - | 2022-08-24 | 130 | 6619 | 5 | |
不瑶碧莲 | 免疫系统在嘎嘎乱杀中… | Java工程师 | - | 2021-11-28 | 399 | 362 | 3 | |
HoMeTown | 行,你真有眼光 | 公众号 | 秃头开发头秃了 | 2020-09-13 | 840 | 14670 | 5 | |
钱得乐 | - | - | 掌阅科技 | 2021-04-26 | 615 | 5154 | 4 | |
Cobyte | 我们每天几乎都在学习新的知识,但如果没有进行归纳总结,就会非常凌乱和容易遗忘;所以我主要是记录个人的一些学习札记,如有错漏,恳请斧正,如恰能有助于你,则感谢勤奋的你吧。 | 🏆掘金签约作者 ● 小小前端,伪全栈 | - | 2021-06-12 | 568 | 10596 | 5 | |
跟着飞哥学编程 | 公众号:民谣嗑学家 主Java后端,致力于全栈发展,活在民谣里的程序员。业余吉他爱好者,没事写写公众号和博客。 | 全栈开发工程师 | 一家很牛逼的互联网公司 | 2022-03-03 | 304 | 111 | 2 | |
代码与野兽 | 关注real-time web、低代码、数据可视化、web3等领域。 | 公众号@代码与野兽 | 保密 | 2019-09-30 | 1189 | 17869 | 5 | |
进军的王小二 | 一枚吃货~ | 前端攻城狮 | 不知名小公司 | 2020-07-23 | 892 | 9205 | 5 | |
vaelcy | - | 前端开发工程师 | 某上市公司 | 2021-06-29 | 551 | 8149 | 5 | |
子不语Any | If not now,when? | 安卓攻城狮 | 编程美学 | 2019-11-14 | 1144 | 3662 | 4 | |
奔波儿灞取经 | 语言底层是算法,系统底层是架构,算法跟架构都是思想。 | Blog | AndroidUFO | 2021-03-01 | 671 | 12024 | 5 | |
逍丶 | - | 前端小菜鸟 | - | 2022-05-03 | 243 | 14536 | 5 | |
聪小陈 | 🌈 umi 核心开发人员,alita 作者 v yu_xiaohu | 前端 | - | 2019-11-19 | 1139 | 7588 | 5 | |
清欢bx | https://github.com/LBINGXIN | 前端架构师 | - | 2022-06-08 | 207 | 2720 | 4 | |
南山种子外卖跑手 | 仰望星空,脚踏实地,逐步前行! | 🏆掘金签约作者 | 腾讯 | 2022-01-13 | 353 | 5353 | 4 | |
CoderHing | 专注于前端开发 | 前端开发工程师 | - | 2022-09-30 | 93 | 223 | 2 | |
夏志121 | 活到老,学到老 | - | - | 2022-10-07 | 86 | 1015 | 3 | |
姚明振 | - | iOS 开发 | 订单来了 | 2021-12-12 | 385 | 466 | 3 | |
大眼睛图图 | 我往前飞,飞过一片时间海 ——《遇见》 | - | - | 2022-05-02 | 244 | 3710 | 4 | |
一一哥Sun | 孙玉昌,十年软件开发授课经验,专注大学生毕设及面试求职私塾式指导!CSDN博客专家,阿里云、infoQ专家博主。对Java/Android/H5等有深入研究!曾任国内物流行业独角兽企业架构师,现任某知名教育公司技术研发总监 | 技术研发总监 | 北京千锋互联科技有限公司 | 2022-09-28 | 95 | 5282 | 4 | |
默海笑 | 表里不一的正人君子~ | 表里不一的正人君子~ | - | 2022-01-01 | 365 | 2785 | 4 | |
吓死羊了 | - | 明天的全栈工程师 | 一直在学习 | 2021-01-24 | 707 | 4309 | 4 | |
尚影嫣 | 你当像鸟飞往你的山 | Java | - | 2022-04-23 | 253 | 2560 | 4 | |
新生代农民工No1 | 我的愿望:世界和平;world peace;Мир во всем мире; | iOS & Flutter | - | 2021-09-05 | 483 | 2808 | 4 | |
19组清风 | 满怀希望,就会所向披靡! | FE | 19组 | 2018-12-08 | 1485 | 11849 | 5 | |
茶无味的一天 | 代码首先是写给人看的,附带能在机器上运行的功能。 | FE | 灵活就业人员 | 2021-05-31 | 580 | 13819 | 5 | |
jerryfans | 一个iOS开发者,现在在研究Flutter跨平台技术. | Swifter & Flutter | 逸风 | 2019-09-10 | 1209 | 2198 | 4 | |
荣顶 | 面向快乐编程~🥰 | 🏅掘金签约作者丨公众号:前端超人 | - | 2020-11-29 | 763 | 12130 | 5 | |
叶一一 | 苍生涂涂,天下缭燎,诸子百家,唯我纵横 | 非职业「传道授业解惑」的程序媛,「趣学前端」、「CSS畅想」系列作者,华夏美食、国漫、古风重度爱好者,刑侦、无限流小说初级玩家。 | 前端开发 | 某保险科技公司 | 2021-08-17 | 502 | 8730 | 5 | |
许进进 | - | - | - | 2018-06-21 | 1655 | 2615 | 4 | |
战场小包 | 成长型研究僧,五湖四海皆兄弟,欢迎来和小包交朋友。 wechat: li444186976 | 公众号: 小包学前端 | - | 2021-09-08 | 480 | 27174 | 5 | |
夕水 | 喜欢代码,读书,文学 | web前端开发 | - | 2019-04-10 | 1362 | 5609 | 5 | |
熊的猫 | 业精于勤立不易方,而后鹏程万里!以己之长,学人之长! | 前端开发 | - | 2021-03-14 | 658 | 13149 | 5 | |
二流小码农 | 一个北漂的二流程序员 | Android开发 | - | 2018-05-04 | 1703 | 2378 | 4 | |
一条会coding的Shark | 热爱摸鱼~ 欢迎来摸~ | 前端 | - | 2022-04-26 | 250 | 4110 | 4 | |
魏铁锤 | 今朝若是同淋雪,他日也算共白头 | Java软件设计 | 南阳科技有限公司 | 2022-07-04 | 181 | 1224 | 3 | |
Ziu | 你好,世界 👋 | 前端首席摸鱼师 | FishTouch科技 | 2022-04-19 | 257 | 3727 | 4 | |
清秋 | 你好,我是清秋,一个有着教师梦的 Web 前端非典型程序员。业余画家、设计师、写手,PMP,数据挖掘背景。北邮硕士毕业后一直在某股份制银行软件开发部工作,一晃已经七年了。 | Web前端 | 公众号:Frontend Radio | 2018-03-27 | 1741 | 8392 | 5 | |
ndz | 放弃不难,但坚持一定很酷。 | 🏆 掘金签约作者 | - | 2021-08-14 | 505 | 17446 | 5 | |
前端那些年 | 公众号《javascript高级程序设计》 热爱技术、喜欢写作、渴望自由 | 前端开发 | 五金冲件厂 | 2019-07-17 | 1264 | 6569 | 5 | |
叶秋学长 | CSDN内容合伙人,阿里云大咖问答开发与运维版板主,阿里云专家博主,华为云享专家博主,全栈领域创作者 | 全栈工程师 | - | 2022-07-13 | 172 | 3729 | 4 | |
前端胖头鱼 | 会一点点前端 | FE | 公众号: 前端胖头鱼 | 2016-10-24 | 2260 | 55624 | 6 | |
CodeFox | 动态线程池DynamicTp作者,Nacos、Dubbo、RocketMq等开源项目贡献者,专注后端领域,跟你一起变强! | 微信搜:CodeFox | - | 2022-01-16 | 350 | 6652 | 5 | |
纪先生 | 公众号:纪先生笔记(时刻雕刻你的身体&&灵魂) | 服务端|公众号:纪先生笔记 | - | 2021-07-22 | 528 | 5293 | 4 | |
格格步入 | 我有两把键盘,一把用来编织世界,一把用来剖析心灵 | 软件安装工程师 | - | 2020-03-05 | 1032 | 8405 | 5 | |
低调的牛魔王 | 低轨卫星通信核心网工程师 | 未来出行星座核心网工程师 | - | 2021-02-13 | 687 | 1831 | 4 | |
神奇的程序员 | 今天的努力只为未来 | 全干工程师(主前端,副后端) | 广州某中型公司 | 2019-09-08 | 1211 | 32159 | 6 | |
Kagol | Vue DevUI 开源组件库和 EditorX 富文本编辑器创建者,专注于前端组件库建设和开源社区运营。 | Vue DevUI 作者 | 华为 | 2022-11-12 | 50 | 492 | 3 | |
阿佩佩 | - | - | - | 2022-06-27 | 188 | 11 | 1 | |
石云升 | 凡是过往,皆为序章。 | 产品经理 | 公众号:石云升SYS | 2021-11-06 | 421 | 7550 | 5 | |
三掌柜 | 一分耕耘,不一定有一份收获,但十分耕耘,一定会有一分收获 | 架构师 | 某某某科技有限责任公司 | 2021-01-15 | 716 | 1512 | 3 | |
王有志 | 代码是我的文字,程序是我的诗篇,我不是程序员,我是诗人。 | - | 公众号:王有志 | 2020-07-07 | 908 | 2029 | 4 | |
桃小瑞 | - | 前端开发工程师 | - | 2021-07-25 | 525 | 1879 | 4 | |
Bug终结者_ | Java领域优质创作者,Java开发工程师,努力的成长为一个强大的工程师~ | Java软件工程师 | - | 2022-01-25 | 341 | 1006 | 3 | |
前端南玖 | 微信:NANJIU-SY | 公众号:前端南玖 | - | 2021-03-16 | 656 | 15999 | 5 | |
我不是外星人 | 小册《React进阶实践指南》已上线~,公众号: 前端Sharing, 不蹭热度,不发水文。进 React进阶技术交流群 请加微信 TH0000666 | 🏆掘金签约作者 | 攻粽号:前端Sharing | 2020-06-10 | 935 | 52724 | 6 | |
TT_Close | 独立开发者 开发路上的苦行僧 创业调味品 记录🍺分享旅途 | 移动端高级工程师 | 火之夜 | 2022-06-22 | 193 | 4143 | 4 | |
XboxYan | - | 前端侦探 | 阅文集团 | 2018-11-21 | 1502 | 14137 | 5 | |
Finbird | 借风使力,不停的划水吧 | 大前端 | - | 2021-09-15 | 473 | 4419 | 4 | |
不想说话 | 想做出有趣的事情 | 前端开发 | 快手 | 2022-01-07 | 359 | 209 | 2 | |
想赚点零花钱 | 不想摆烂的女程序员,努力不摆烂中…. | 前端开发 | - | 2022-11-29 | 33 | 724 | 3 | |
郑居中 | 奉饶天下先 | 白帝城城主 | - | 2021-12-13 | 384 | 64 | 2 | |
somliy | 散装Java在北京 | Java开发工程师 | - | 2020-02-13 | 1053 | 538 | 3 | |
初心酱 | 选择跟什么样的人在一起做什么样的事,很重要; 真正的大师永远怀着一颗学徒的心 | 摸鱼大师 | - | 2019-07-08 | 1273 | 902 | 3 | |
蚂蚁背大象 | 为往圣继绝学!人要有要有遥不可及的梦想也要有脚踏实地的本事! | 🚀Java开发🚀 | 广州不知名小公司⚡ | 2020-05-11 | 965 | 9884 | 5 | |
遇渐渐 | vue | 前端工程师 | - | 2022-06-19 | 196 | 302 | 3 | |
云雨雪 | 学点新技术,写点小文章,生活美滋滋 —–懒惰的我正自我鞭策中 | Java菜恐龙(远古的火箭追着我跑) | - | 2022-04-18 | 258 | 1281 | 3 | |
小野学Java | - | Java开发 | - | 2021-12-30 | 367 | 759 | 3 | |
十七喜欢前端 | 优质代码追求者 | 前端 | - | 2022-05-12 | 234 | 3224 | 4 | |
Somnus_小凯 | 永远相信美好的事情,即将发生 | 项目经理 | 深圳微品致远信息科技有限公司 | 2020-03-16 | 1021 | 604 | 3 | |
桑小榆呀 | 你看这个码农,不仅码的好,还会写文章且会赚钱呀。 公众号:桑小榆呀 | 后端开发 | 日向 | 2022-06-27 | 188 | 2485 | 4 | |
在下uptown | - | 练习时长两年半的夹娃练习生,喜欢Ctrl+C、Ctrl+V、Ctrl+Z。 | - | 2022-04-20 | 256 | 538 | 3 | |
楚楚北北 | - | cv工程师 | 什么公司? | 2022-10-20 | 73 | 300 | 3 | |
LolitaAnn在掘金 | 搞算法,NLP方向。 | - | - | 2021-07-09 | 541 | 7189 | 5 | |
大鸡腿同学 | SofaRpc contribuer; Discovery 提交多个issue; 21年拿到阿里淘系口头offer; 目前在某公司架构组搬砖,多多指教~ | Java架构师 | - | 2022-04-21 | 255 | 11210 | 5 | |
穆雄雄 | - | 技术经理 | 山东睿泽网络科技有限公司 | 2022-11-08 | 54 | 839 | 3 | |
卷帘依旧 | FE | 公众号 | 我是前端喵 | 2020-05-12 | 964 | 2213 | 4 | |
鳄鱼儿 | - | - | - | 2022-07-27 | 158 | 1201 | 3 | |
Daisy_ | 前端小辣鸡 | 前端 | - | 2022-08-10 | 144 | 212 | 2 | |
前端bubucuo | 全职学习React源码3年 | 公众号:bubucuo, b站: 前端bubucuo | - | 2020-11-06 | 786 | 3455 | 4 | |
JYeontu | 喜欢算法,GDCPC打过卡;热爱羽毛球,大运会打过酱油。毕业一年,两年前端开发经验,做过unity游戏开发,目前担任H5前端开发,算法业余爱好者。 | 前端 | - | 2021-08-28 | 491 | 8004 | 5 | |
xcc | keep loving, keep coding. Respect to antfu👍. | 前端程序猿 | Element Plus 团队成员 | 开源noob | - | 2022-02-10 | 325 | 558 | 3 | |
一个前端人 | React、Ant-design、Zent、Wyn | Front end development engineer | - | 2021-12-13 | 384 | 5520 | 5 | |
靖安 | 人生苦短,多吃薯条 ——某不愿留名的海鸥 | 后端 | - | 2022-08-10 | 144 | 211 | 2 | |
忆想不到的晖 | 用Code谱写生活,让世界更有趣 | 后端开发 | - | 2020-04-17 | 989 | 4996 | 4 | |
吃猫的鱼_ | 博客地址:https://lijunyi.xyz | JAVA | @公众号 A佳技术 | 2019-03-27 | 1376 | 1003 | 3 | |
秃头小苏 | 爱踢足球的程序猿⚽⚽⚽ 喜欢在操场挥洒汗水,无奈抱着电脑编程💻💻💻 | 🏆掘金签约作者 3D视觉开发者社区优质内容博主 阿里云博客专家 | - | 2022-02-26 | 309 | 4334 | 4 | |
微之风 | 我是一颗卷心菜,心里想卷,但是很菜! | 前端开发 | - | 2021-07-08 | 542 | 1222 | 3 | |
小可爱杀手 | 2020年划水总冠军,2021年bug制造者… | 学生 | - | 2021-08-12 | 507 | 301 | 3 | |
jecyu | 坚持原创,用心写文。分享前端技术实践,包括不限于小程序、计算机网络、React、Vue 等技术 | 开发 | 木叶村 | 2019-06-08 | 1303 | 3998 | 4 | |
芝麻粒儿 | 需要各种资源分享(网站、工具、素材、源码、游戏等),欢迎联系交朋友。 | 微信:XQL8686 | - | 2021-08-01 | 518 | 11798 | 5 | |
用户7210340961494 | - | - | - | 2022-08-05 | 149 | 1378 | 3 | |
小孔融 | 只要心中有理想,就有地方叫做闯! | - | 云恒大数据中心 | 2022-12-26 | 6 | 14 | 1 | |
咕噜咕噜吨吨吨 | - | - | - | 2022-06-27 | 188 | 10 | 1 | |
zxhtom | 是时候底层结构了解了。不能仅仅局限于curd | 公众号 | zxhtom | 公众号,微信同名 | 2017-10-17 | 1902 | 16654 | 5 | |
codeniu | 前端开发工程师 | 前端开发工程师 | - | 2020-12-10 | 752 | 2725 | 4 | |
鲁班代师 | 一个图形领域懂点技术的数学人。 b站主页:https://space.bilibili.com/447301957?spm_id_from=333.1007.0.0 | C++图形开发工程师 | - | 2022-08-03 | 151 | 1038 | 3 | |
iiopsd | 边跑步边看美剧,边工作边学习的程序员 | JAVA | XZ | 2022-11-06 | 56 | 1951 | 4 | |
鸭鸭世界第一可爱 | 鸭鸭要冬眠,《萌妹高级进阶指南》 | java后端 | 我是萌妹 | 2021-12-09 | 388 | 295 | 3 | |
阿兵云原生 | 可以关注公众号:阿兵云原生 擅长c/c++,golang | 公众号 | 阿兵云原生 | - | 2021-02-09 | 691 | 18957 | 5 | |
夏沫的梦 | 人生苦短,我学Golang | Golang工程师 | 应急管理大学 | 2022-09-26 | 97 | 4515 | 4 | |
新一代螺丝工 | 创作不易,求求点个赞吧🥺 | 客户端、元宇宙 | - | 2019-05-20 | 1322 | 2501 | 4 | |
李坤 | 人生是公平的,你只管努力,时间会给你答案,哪怕结果会迟到,但决不会缺席。 | iOS | - | 2019-12-01 | 1127 | 2062 | 4 | |
Mool | 事事有回应 件件有着落 | 前端 | - | 2021-05-09 | 602 | 2331 | 4 | |
CoderBin | “普通人只考虑他们将如何度过时间,而有智慧的人则试图利用时间。” — CoderBin 前端萌新 | 学生 @ 前端萌新 | - | 2022-06-25 | 190 | 6268 | 5 | |
芥末拌饭 | - | 后端,大数据 | - | 2022-08-06 | 148 | 2221 | 4 | |
沐华 | 与代码交手这些年,你是否光彩依旧,生机盎然? | 公众号:前端快乐多 | - | 2020-04-26 | 980 | 29732 | 6 | |
Pika | 一个神奇的android开发 | 🏆掘金移动端签约作者|Android开发 | - | 2022-01-29 | 337 | 6593 | 5 | |
安小轩 | - | web前端 | - | 2021-02-04 | 696 | 3699 | 4 | |
牛不灭 | - | - | - | 2022-05-04 | 242 | 342 | 3 | |
XINO | 在校学生,网络安全爱好者,CTFer | 学生,网络安全,CTFer | - | 2022-06-02 | 213 | 4316 | 4 | |
苏世_ | 喜欢各种尝试、折腾的程序员 | java开发工程师 | 北京某不知名互联网公司 | 2021-06-24 | 556 | 5555 | 5 | |
清风无影 | 道法自然 | 前端主管 | - | 2022-08-27 | 127 | 1020 | 3 | |
奔跑的水瓜 | - | HTML开发 | - | 2021-02-04 | 696 | 340 | 3 | |
UOrb | 一个路过的图片分割机 | 前端 | - | 2019-11-19 | 1139 | 2109 | 4 | |
能给我说晚安吗 | 菜菜 | 菜菜运营 | 菜菜公司 | 2021-06-24 | 556 | 22 | 1 | |
RiemannHypothesis | 微信号JingnanSJ或者公众号RiemannHypo获取异步和图灵系列书籍, | QA | RiemannHypo | 2021-12-10 | 387 | 14110 | 5 | |
鱼丸仙仙 | 大四在校前端学习ing | 前端开发实习 | 滴滴 | 2022-04-09 | 267 | 3442 | 4 | |
莫浅子 | - | - | - | 2022-10-04 | 89 | 1197 | 3 | |
嘿嘿Z | 啊,大海,你全是水!!! | 🐶护体 | 纯纯私房菜,好不好吃另说🐶 | 2019-10-23 | 1166 | 6366 | 5 | |
阿李贝斯 | 技术公众号:阿李贝斯的白日梦 | 前端工程师 | - | 2019-05-23 | 1319 | 4151 | 4 | |
Eddie | Learning doesn’t stop there | Code Porter | - | 2019-10-21 | 1168 | 808 | 3 | |
李之阳 | 我是李之阳,深耕Android行业、嵌入式Linux行业、音视频方向,专注于系统性能、性能优化、稳定性建设,热爱开源,喜欢分享,关注我,带你看技术的诗与远方…. | 资深技术专家 | vim++ | 2022-01-21 | 345 | 214 | 2 | |
Cora | - | 前端开发工程师 | 中通 | 2021-11-11 | 416 | 451 | 3 | |
六号积极分子 | 正前往架构师路途之中…… | 架构学习积极分子 | - | 2019-05-07 | 1335 | 6840 | 5 | |
嵌入式视觉 | 关于博主,本科双非一本,曾3个半月考研上岸211硕士,现大厂算法工程师,从事视觉算法开发和模型压缩部署工作,终身学习践行者。 | 算法工程师 | 商汤科技 | 2022-10-13 | 80 | 1768 | 3 | |
挽烽 | - | - | - | 2022-10-01 | 92 | 1948 | 4 | |
祯不错 | - | - | - | 2021-12-11 | 386 | 146 | 2 | |
自由了 | 越努力越幸运 | 2022稀土掘金周边体验官 | 自律 自由 | 2019-04-18 | 1354 | 4228 | 4 | |
菜菜的后端私房菜 | 专注Java后端技术栈,热爱工作,热爱生活,关注菜菜,分享更多干货日常哟~ | Java开发 | 菜菜 | 2022-05-15 | 231 | 1901 | 4 | |
我们一起 | Flutter爱好者 | - | - | 2022-09-17 | 106 | 270 | 2 | |
流浪法师 | 我有一把大砍刀(长49米) | CV大法师 | - | 2021-03-03 | 669 | 7306 | 5 | |
zxg_神说要有光 | 小册《前端调试通关秘籍》已上线 | 神光的编程秘籍 | - | 2019-02-18 | 1413 | 69538 | 6 | |
二当家的白帽子 | 一起加油吧,希望我们大家都能每天进步一点点,成为我们想要成为的那个人~~~~~ | 高级系统架构师 | - | 2021-08-09 | 510 | 5155 | 4 | |
程序员Better | 努力! 奋斗!我们一起学习 | 前端学习搬砖人 | 公众号:程序员Better | 2020-03-07 | 1030 | 5190 | 4 | |
TechMerger | 微信「ELC1020」,公众号「TechMerger」 | Android Developer | - | 2021-04-13 | 628 | 8272 | 5 | |
JavaEdge在掘金 | 关注回复“面试”,白嫖大厂求职必过资源 | 公众号 | JavaEdge | 2018-04-09 | 1728 | 10541 | 5 | |
萱辰01 | 自己选的路那就努力走好! | 前端工程师 | - | 2019-12-13 | 1115 | 2559 | 4 | |
Ciusyan | 人生没有白走的路,你走的每一步都算数 | 还大学生呢,这不**吗~ | - | 2022-07-06 | 179 | 822 | 3 | |
进击的大葱 | 关注我,你会变得更强。 | Tech Lead | 进击的大葱公众号 | 2018-12-12 | 1481 | 5004 | 4 | |
颜海镜 | 前端技术博主,《现代JavaScript库开发:原理、技术与实战》、《React状态管理与同构实战》作者 | 前端 | jsmini | 2018-09-13 | 1571 | 10115 | 5 | |
小小达人 | 星星应该哈哈大笑,反正宇宙是个偏僻的地方。啊哈哈哈 | 前端 | - | 2022-04-06 | 270 | 35 | 1 | |
江子麟 | 我觉得从某种意义上来说,不是我选择了前端,而是前端选择了我 | 中国未顶级前端工程师 | - | 2022-07-29 | 156 | 596 | 3 | |
佑子呀 | - | 前端 | - | 2021-09-29 | 459 | 4465 | 4 | |
万恶的沫白 | - | 后端开发 | - | 2021-03-24 | 648 | 2844 | 4 | |
wayn | coder,java,php | 全栈 | wayn | 2020-03-19 | 1018 | 1498 | 3 | |
辉夜真是太可爱啦 | 个人网站:https://www.cooldream.fun | 前端开发 | - | 2020-02-25 | 1041 | 4885 | 4 | |
Brucebat | 竹杖芒鞋轻胜马,谁怕?一蓑烟雨任平生(一条有梦想的咸鱼程序猿,公众号:Brucebat的伪技术鱼塘) | Java程序猿 | 公众号:Brucebat的伪技术鱼塘 | 2020-05-30 | 946 | 1600 | 3 | |
Java星辰 | 精通Java、Rust、Python、C、C++、C#、Ruby、Swift、Objective-C、Pascal等单词的拼写,熟悉Windows、Linux、Mac、鸿蒙、Android、IOS、WP8、WP10等系统的开关机。 | Java高级工程师 | - | 2022-09-10 | 113 | 2289 | 4 | |
梦想实现家_Z | java/rust 多写bug,别秃头 | java开发、rust开发 | - | 2022-06-05 | 210 | 4576 | 4 | |
xn213 | - | 头号沸猿在线摸鱼 | - | 2019-11-20 | 1138 | 4229 | 4 | |
孤独的红心 | - | 后端开发 | - | 2022-04-25 | 251 | 1721 | 3 | |
海绵宝宝_0113 | 20级在读 软件工程 | 学生 | - | 2022-06-11 | 204 | 3319 | 4 | |
董员外 | 距离成为百年老程序员还差98年… | 公众号 | oldCode | 2020-07-12 | 903 | 5153 | 4 | |
前端小凝 | - | 曾就职华为美团平安/高级前端工程师 | - | 2022-07-10 | 175 | 131 | 2 | |
moe_ | 不喜欢别人的韵脚 丨 人在大连丨 技术交流➕微信:moe_0321 | 前端摸鱼带砖家 | OCDL | 2020-03-13 | 1024 | 3302 | 4 | |
金虹桥程序员 | - | 前端攻城狮 | 百度 | 2021-08-03 | 516 | 3815 | 4 | |
薛定谔的猫酱 | - | 前端 | 掘金首席产品体验官 | 2021-07-16 | 534 | 129 | 2 | |
上进小菜猪 | gowork | 学生 | 猿起科技有限公司 | 2022-03-01 | 306 | 4022 | 4 | |
程序员读书 | 发发呆,品品茶,敲敲代码,写写文章,读读好书,追追好剧,看看大片 | 公众号:程序员读书 | - | 2019-03-04 | 1399 | 10376 | 5 | |
一颗卷心菜QAQ | 摸鱼小能手 | 测试小摸鱼 | - | 2022-08-12 | 142 | 104 | 2 | |
ZZCCCCLL | - | - | - | 2022-07-11 | 174 | 78 | 2 | |
慕枫技术笔记 | InfoQ签约作者,阿里云专家博主,CSDN博客专家、专注源码分析、架构设计、分享所思所想 | 公众号:慕枫技术笔记 | Alibaba | 2021-03-30 | 642 | 7325 | 5 | |
东方淼淼 | 前端小白 摩托车爱好者 周易小学生 | - | - | 2021-05-06 | 605 | 5603 | 5 | |
ObliviateOnline | 安卓开发积极分子 | 安卓开发工程师 | 某监控设备方案公司 | 2022-07-28 | 157 | 3732 | 4 | |
只会番茄炒蛋 | 7 年互联网行业 web 前端开发经验,熟练掌握前端架构设计与主流开发技术,能独立完成项目从需求分析到系统上线的全流程管理。 | 大头兵 | 只会番茄炒蛋有限公司 | 2019-03-15 | 1388 | 12770 | 5 | |
Masters | 以解决问题为驱动力 | Gopher | 脑瓜疼 | 2022-02-24 | 311 | 819 | 3 | |
呛再首 | 前已无通路,后不见归途 | 失业 | 单间、切图 | 2019-07-04 | 1277 | 12147 | 5 | |
盏灯 | 大胆点,多看多想多敲多调多经历多尝试坚持。 问题能带来情绪,情绪不能解决问题。 差不多才会嫉妒,差太多只能羡慕。 比完美更重要的是完成。 快速行动,破除陈规。 保持专注,持续发布。 | 砖太烫汗太咸 | - | 2019-09-03 | 1216 | 2116 | 4 | |
宁轩 | 点赞小能手帮我赞一下文章, 有赞必回 | - | - | 2022-05-30 | 216 | 3641 | 4 | |
程序员界的小学生 | Android、Flutter、iOS | 移动端高级工程师 | 绘玩科技有限公司 | 2020-08-10 | 874 | 5078 | 4 | |
Linn | 加倍努力才能离梦想更近一步 | Java开发 | - | 2019-05-28 | 1314 | 2249 | 4 | |
抖音小凯 | - | - | - | 2022-09-14 | 109 | 10 | 1 | |
九酒 | 一直在走神 | 前端练习生 | - | 2018-04-01 | 1736 | 1722 | 3 | |
老边 | 一个喜欢开发,喜欢分享的编程工程师,当过编程讲师,做过全栈项目,喜欢和大家聊天,享受一起进步的过程。 | 全栈工程师 | - | 2022-10-17 | 76 | 3825 | 4 | |
狂奔滴小马 | 你不一定要很厲害,才能開始;但你要開始,才能很厲害 | 前端公众号 | JS酷 | 2020-09-17 | 836 | 20840 | 5 | |
颜如玉 | 无用之人,恍惚廿余载 | Java混子 | 离职在家 | 2020-01-04 | 1093 | 1882 | 4 | |
lebronzhen | Android | 码农 | - | 2020-05-25 | 951 | 1385 | 3 | |
修之竹子 | 公众号【修之竹】关注Android 技术,还有成长道路上的点滴记录、思考,欢迎关注,与我一同成长,一同收获幸福~ 微信号 xiuzhizhu ~ | Android 公众号 @修之竹 | - | 2021-07-24 | 526 | 525 | 3 | |
chokcoco | 国服第一切图仔 | - | iCSS前端趣闻 | 2016-06-20 | 2386 | 104169 | 7 | |
卡布1达咩 | 在夕阳的余晖中我出生了 迎接我的是黑暗和寒冷 以为还能看到太阳拥有温暖 却忽略了夜的漫长和折磨 怀揣着记忆中太阳的模样 结果冻死在了黎明拂晓 | 烧火的添柴员 | 星星之火火种无限公司 | 2020-12-10 | 752 | 2970 | 4 | |
沃和莱特 | 每一个不曾起舞的日子都是对生命的辜负。 | 高校学生 | - | 2022-04-30 | 246 | 427 | 3 | |
末世未然 | 犯其至难而图其至远 | 前端工程师 | lw2022 | 2021-02-01 | 699 | 4786 | 4 | |
公众号iOS逆向 | 移动开发领域新星创作者,分享iOS、小程序开发与运营、阅读与写作。 只为你呈现有价值的信息,专注于移动端技术研究领域。 更多资讯和服务请关注#小程序:iOS逆向、#公众号:iOS逆向 https://kunnan.blog.csdn.net | iOS高级工程师 | 公众号:iOS逆向 | 2020-12-02 | 760 | 14379 | 5 | |
小花皮猪 | Java程序猿 | Java开发 | - | 2022-11-28 | 34 | 745 | 3 | |
Hsiao | 前端的入门新手一枚吖~ | 学生 | - | 2022-11-03 | 59 | 294 | 3 | |
lambert9797 | - | php | - | 2022-12-07 | 25 | 10 | 1 | |
陈明勇 | 一个热爱技术,喜欢专研技术的程序员。 | 后端开发工程师 | - | 2022-04-27 | 249 | 1774 | 3 | |
codinglin | - | - | - | 2022-04-10 | 266 | 2161 | 4 | |
来瓶二锅头00 | 吃 | 前端开发 | 某互联网公司 | 2022-04-01 | 275 | 682 | 3 | |
陈言必行 | 个人微信:czy59421;关注公众号:“开发同学留步”;领取我为你精心准备的程序书籍,另有几十款经典游戏源码等你来取哦~ | 游戏开发攻城狮 | Unity | 2021-07-29 | 521 | 8001 | 5 | |
hauk0101 | 折腾不止于前端 | 攻城狮 | 公众号闲散将军府 | 2018-03-01 | 1767 | 2194 | 4 | |
Zeuss | 早买早享受,晚买打折扣,不买免费送 | - | - | 2022-07-10 | 175 | 4211 | 4 | |
那个曾经的少年回来了 | 信自己没有什么不可以!!! | - | 公众号:那个曾经的少年回来了 | 2021-02-01 | 699 | 7203 | 5 | |
李知恩 | - | 前端 | - | 2021-04-26 | 615 | 2297 | 4 | |
ho | 摸鱼,烤鱼,炸鱼,炒鱼,钓鱼,买鱼,养鱼,除了摸鱼其他都不会 | 渣渣前端 | 武汉html公司 | 2018-08-15 | 1600 | 4553 | 4 | |
行百里er | chendapeng.cn - 行百里者半九十,凡事善始善终,吾将上下而求索。 | 博客:https://chendapeng.cn | - | 2020-09-19 | 834 | 6248 | 5 | |
码农参上 | 公众号“码农参上”作者,爱好美食、运动、摄影、ACG的程序猿。 | 公众号【码农参上】 | - | 2021-03-28 | 644 | 5828 | 5 | |
阿乐去买菜 | - | 前端 | - | 2020-06-13 | 932 | 3843 | 4 | |
饼干_ | 咸鱼ing | 掘金优秀码农 | git | 2021-04-22 | 619 | 8613 | 5 | |
Maic | 公众号:Web技术学苑 专注前端技术、分享web技术 | 前端工程师 | - | 2022-05-07 | 239 | 2290 | 4 | |
源心锁 | 深圳技术大学23届学生,要努力学前端,腾讯前端实习生 | 前端工程师 | TX | 2021-08-22 | 497 | 2466 | 4 | |
蝎子莱莱爱打怪 | 纸上得来终觉浅,绝知此事要躬行。 | Java攻城狮 | 出行公司 | 2020-03-15 | 1022 | 1129 | 3 | |
架构精进之路 | 公号「架构精进之路」,专注软件架构研究,技术学习与职业成长! 坚持原创总结、沉淀和分享,感谢各位的支持(关注、点赞、分享)! | 软件架构 | 公众号:架构精进之路 | 2020-09-23 | 830 | 3704 | 4 | |
Livingbody | 我期待有一天,我拿起键盘,只为了爱好编程,只为了快乐打游戏,而不是迫于生计蹲电脑🤓🤓🤓 | Big Boss | Sky Net Cor | 2021-10-21 | 437 | 7364 | 5 | |
new_cheng | 小岛前端 | - | - | 2020-05-12 | 964 | 1207 | 3 | |
竹子爱熊猫 | 知识改变命运,学习永无止境。 | 🏆掘金签约作者 | Java技术专家-菜鸟 | 2021-06-24 | 556 | 14596 | 5 | |
夏雨,影韵 | 喜欢烹饪,旅游,看书,写作! | 前端开发 | - | 2019-11-05 | 1153 | 452 | 3 | |
itbird01 | 细节决定成败,专注决定高度 | android | - | 2022-03-09 | 298 | 2083 | 4 | |
矜辰所致 | 不浮夸,不将就,认真对待学知识的我们,矜辰所致,金石为开! 为了活下去的嵌入式工程师,画画板子,敲敲代码,玩玩RTOS,搞搞Linux … | 嵌入式高级工程师 | 南京汇尚网络科技有限公司 | 2022-08-24 | 130 | 3508 | 4 | |
我亚索贼六丶 | 别卷了,卷不动了。 | cv工程师 | 上海 | 2019-10-28 | 1161 | 2004 | 4 | |
码bug的小砖家 | Daily work is coding bugs. | 程序猿 | CVTE | 2020-06-03 | 942 | 726 | 3 | |
0o华仔o0 | - | 🏅 掘金签约作者 | 前端开发 | - | 2019-08-15 | 1235 | 10894 | 5 | |
语择 | 艾泽拉斯土地上的一个小法师 | 大前端@小菜鸟 | - | 2017-03-04 | 2129 | 258 | 2 | |
百里落云 | 摸鱼大队长 | - | - | 2022-09-02 | 121 | 1375 | 3 | |
AE860 | - | Android开发 | - | 2018-12-19 | 1474 | 4339 | 4 | |
静Yu | CSDN优质创作者:静Yu,公众号:知识小海洋,分享各种学习资料书籍. | - | - | 2021-10-15 | 443 | 2097 | 4 | |
前端第一渣男 | - | 前端 | 渣男养成记 | 2021-05-18 | 593 | 189 | 2 | |
掘了 | 真正的大师,永远怀着一颗学徒的心 | XMU | ByteDance | 2021-03-05 | 667 | 6735 | 5 | |
三人行丨 | 五岁浪迹天涯 🌋 从未迷失本心 | 前端 | 斯塔克工业 | 2021-05-29 | 582 | 530 | 3 | |
菁芜 | 一路是坎坷,一路是风景 | - | 2018-10-25 | 1529 | 826 | 3 | ||
黄刀小五 | 菜鸡前端一只 | 前端 | Deeruby | 2021-01-24 | 707 | 2878 | 4 | |
nathan_ll | 世界和平 | QDGCS | - | 2019-07-23 | 1258 | 742 | 3 | |
伯nulee | 公众号:伯nulee | 小瘪三 | 原来你也是小瘪三 | 2021-04-22 | 619 | 796 | 3 | |
strp_无问 | - | 前端工程师 | - | 2022-07-05 | 180 | 245 | 2 | |
起一个可以中奖的名字 | - | 软件开发 | - | 2022-02-23 | 312 | 151 | 2 | |
qb | - | - | - | 2019-05-29 | 1313 | 3743 | 4 | |
Loken1 | 音视频工程师 xianwaizhiyin.net | 音视频开发工程师 | - | 2022-01-12 | 354 | 3671 | 4 | |
xing_ | 温故而知新 | 前端 | 不知名小公司 | 2021-12-29 | 368 | 3805 | 4 | |
一依不舍 | 当学习成为了习惯,知识也就变成了常识。 | 公众号:前端每日技巧 | - | 2021-04-16 | 625 | 4431 | 4 | |
柒号华仔 | 星光不问赶路人,岁月不负有心人。 | 协议栈@某通信公司 | - | 2022-05-31 | 215 | 2735 | 4 | |
捉虫大师 | 公众号「捉虫大师」 | 中间件开发工程师 | 滴滴 | 2020-04-11 | 995 | 4367 | 4 | |
甜点cc | 公号:看见另一种可能 | 🏆FE/Gopher | - | 2021-10-04 | 454 | 3564 | 4 | |
不减20斤不改头像 | - | - | - | 2020-10-21 | 802 | 1154 | 3 | |
韦路 | 在分享中收获,在总结中成长 | 前端小白 | - | 2021-08-27 | 492 | 811 | 3 | |
YK菌 | 大家好,我是YK菌 🐷 爱思考,爱总结,爱记录,爱分享 🏹欢迎关注我 😘 ~ [微信公众号:YK菌] | 前端领域终身学习者 | 欢迎一键三连哦~ | 2021-02-04 | 696 | 9036 | 5 | |
单总不会亏待你 | - | Flutter/Android开发工程师 | - | 2019-12-17 | 1111 | 1233 | 3 | |
itclanCoder | 微信搜索:itclanCoder 个人站点:https://coder.itclan.cn/ | 前端开发 | - | 2017-07-10 | 2001 | 9701 | 5 | |
JayYuen | 暂无简介 | 暂无职位 | 暂无公司 | 2020-08-04 | 880 | 2472 | 4 | |
HashTang | 一位不知名的前端小开发 | 前端小开发 | - | 2021-12-03 | 394 | 937 | 3 | |
小小喵 | - | 前端开发工程师 | 成都 | 2021-02-07 | 693 | 45 | 2 | |
秋染蒹葭 | 左手天使,右手魔鬼 | 伪前端 | 杭州阿里系内推【zhyjor@163.com】 | 2018-02-02 | 1794 | 2450 | 4 | |
菜猫子neko | 面向掘金编程工程师 | 前端 | 阿里巴巴 | 2021-12-07 | 390 | 6163 | 5 | |
ElvisCat | 前端cv工程师 | 前端工程师 | 灵活就业人员 | 2019-06-24 | 1287 | 896 | 3 | |
Bertil | 不甘平凡,不敢平凡。 | 学生 | - | 2022-04-15 | 261 | 274 | 2 | |
jsmask | 科班出身的散修 | 前端修仙者 | - | 2021-08-11 | 508 | 15125 | 5 | |
易保山 | 每个和尚都应该挖一口属于自己的井 | 移动开发 | - | 2021-12-20 | 377 | 1261 | 3 | |
来快活呀 | - | 保安队长 | - | 2017-01-28 | 2164 | 10514 | 5 | |
田埂 | 专注于 Java开发/源码/架构/算法,阿里云专家博主, 知名互联网公司 后端研发工程师。 | 软件研发工程师 | - | 2022-10-14 | 79 | 594 | 3 | |
摸鱼大队长 | hello | 一个找茬的人 | 神奇的公司 | 2020-07-30 | 885 | 38 | 1 | |
Raymond运维 | 专注于Linux运维自动化、云原生、SRE、DevOps等领域 | - | - | 2022-08-20 | 134 | 3209 | 4 | |
阳呀呀 | - | 前端工程师 | BD | 2019-02-19 | 1412 | 8964 | 5 | |
dz小伟 | - | - | - | 2022-11-06 | 56 | 539 | 3 | |
pekonchan | 1、一个不愿意写简单笔记类,人人都知道的内容,跟别人没差异内容的人 2、只写自己思考实验过,对比甄别过网上资料,提出新观点新想法新理解的文章。 3、笔记类内容可关注公众号 K前端 掘金内容只写有建设性文章 | 大家好,我是pk | - | 2018-12-13 | 1480 | 8357 | 5 | |
陈冠希希 | 掘金关注我,帮我回csdn | - | - | 2022-12-15 | 17 | 380 | 3 | |
北洋 | 记录Android学习之路 分享读书心得体会~ | Android开发工程师 | - | 2021-12-01 | 396 | 4731 | 4 | |
前端若水 | 喜欢自由 | web前端工程师 | USA科技 | 2021-03-18 | 654 | 2866 | 4 | |
Hani | - | web 前端工程师 | 前端成长手册 @公众号 | 2020-05-21 | 955 | 13456 | 5 | |
HerryLo | Javascript、Nodejs | 前端 | 云粒智慧 | 2018-12-04 | 1489 | 3568 | 4 | |
zz | - | 前端 | 布谷鸟工作室 | 2020-07-07 | 908 | 13386 | 5 | |
一咻 | javascript | web前端 | - | 2018-12-28 | 1465 | 2109 | 4 | |
和耳朵 | 纸上得来终觉浅,绝知此事要躬行。 | 🏆 掘金签约作者|点我资料查看Github | - | 2020-07-05 | 910 | 11031 | 5 | |
几何心凉 | 一位萌新前端开发工程师,致力于新技术的推广与优秀技术的普及。 | 前端开发工程师 | - | 2021-07-06 | 544 | 1426 | 3 | |
黑土豆 | 像狗一样奔跑 | 公众号 | 黑土豆的前端博客 | 2021-03-26 | 646 | 4458 | 4 | |
陈梵阿 | 无无无 | 火箭制造工 | 青青草原羊村 | 2022-02-17 | 318 | 559 | 3 | |
Axjy | 技术沉淀与分享(忙ing….💥) | 前端开发工具人 | 又是不想上班的一天 | 2020-08-14 | 870 | 5580 | 5 | |
sherlockkid7 | 学无止境 | - | - | 2022-03-03 | 304 | 1714 | 3 | |
东方小月 | 日拱一卒无有尽,功不唐捐终入海 | 前端全干工程师 | - | 2021-10-14 | 444 | 6748 | 5 | |
coderSlow | 一个保持终身学习态度的前端开发工程师 | web前端工程师 | 浙江之科云创数字科技有限公司 | 2021-06-07 | 573 | 1407 | 3 | |
CookieBoty | 工资到位,四皇干废 | 前端小兵成长营 | - | 2020-04-16 | 990 | 16575 | 5 | |
龙旋 | Android分享者,公众号【龙旋】作者,走在android路上。 | 公众号@龙旋 | - | 2019-06-14 | 1297 | 2404 | 4 | |
1个俗人 | 摸鱼也是对生活的一种抵抗! | 后端|Gopher | - | 2022-02-17 | 318 | 3497 | 4 | |
程序员江同学 | 公众号:程序员江同学 | Android Developer | - | 2020-09-09 | 844 | 21044 | 5 | |
五弦奏南风 | 一个会写后端的前端~ | 前端工程师 | 琴理工作室 | 2022-09-06 | 117 | 856 | 3 | |
天行无忌 | 技术改变生活、研发构建未来、细节铸造品质 | 全栈开发 | DevPoint | 2021-04-14 | 627 | 23593 | 5 | |
陈煮酒 | React / Node.js / 前端工程化 / 稳定性 | 前端工程师 | 字节跳动 | 2021-05-27 | 584 | 438 | 3 | |
共饮一杯无 | 立志做全栈的Java开发者🏄♂️,终身学习者⛷️。 CSDN博客专家,Java领域优质创作者;51CTO 专家博主;华为云享专家; 持续输出。 | - | - | 2022-05-31 | 215 | 12441 | 5 | |
别拿鸭丝不当干部 | 青雲得路何妨晚,勉成国器苦争先。 | 头发茂密的前端 | 医药厂 | 2017-12-15 | 1843 | 1743 | 3 | |
武师叔 | 做一个有趣而不甘平庸的人! | 国内资深摸鱼专家 | 公众号:武师叔 | 2022-04-01 | 275 | 576 | 3 | |
Quasimodo | 愿你用实力让自己的情怀落地! | 落魄前端 | - | 2021-10-08 | 450 | 417 | 3 | |
玛卡bug卡 | 寒风无所惧,云散花自开。 | 后端开发 | - | 2021-03-14 | 658 | 473 | 3 | |
Leecason | wx:Leecason0722 | 公众号:小李的前端小屋 | 字节跳动 | 2018-07-19 | 1627 | 9672 | 5 | |
前端我废了 | Sweat now, glow later. | 前端攻城狮 | - | 2022-03-24 | 283 | 226 | 2 | |
catgod007 | - | 摸鱼新手 | 想得美公司 | 2022-05-19 | 227 | 347 | 3 | |
随身电源 | - | 略 | - | 2019-08-25 | 1225 | 5977 | 5 | |
潘小安 | 一个一直在减肥路上的前端开发攻城狮 | @不务正业的程序员 | 为自己打工有限公司 | 2019-11-08 | 1150 | 1064 | 3 | |
张立梵 | - | - | - | 2022-07-02 | 183 | 805 | 3 | |
Java升级之路 | 挫折是一种散步,全当暂时迷了路。 分享全栈技术干货,一起升级,一起进步, 「Java升级之路」公众号原创作者 | 全栈开发工程师 | - | 2021-07-05 | 545 | 2550 | 4 | |
pixel_revolve | Java,Golang后台开发者。懂一点区块链开发。 | 大学生 | 南京麦趣科技有限公司 | 2021-12-16 | 381 | 1125 | 3 | |
粥里有勺糖 | 你的指尖拥有改变世界的力量 @公众号:粥里有勺糖 | 🏆掘金签约作者 | 前端攻城狮 | 2020-04-18 | 988 | 6527 | 5 | |
宇宙之一粟 | 宇宙无穷,一生不过须臾,当思奋争。混迹于江湖: 热爱技术,轻易不换岗 拒绝内卷,弹性不加班 热衷分享,佛系不水文 | 软件开发工程师&Gopher&Pythonistas | - | 2019-11-15 | 1143 | 7637 | 5 | |
pdudo | - | 运维 | - | 2020-06-09 | 936 | 4369 | 4 | |
度假的鱼 | 之前在CSDN写博客,掘金入住新人。 | - | - | 2022-11-23 | 39 | 871 | 3 | |
ZacheryZHANG | 学吧,学无止境~ 学吧,学海无涯~ | - | - | 2022-03-30 | 277 | 4274 | 4 | |
知心宝贝 | 生于尘埃 溺于人海 死于理想高台 | 公众号 | 穿越计算机的迷雾 | 2022-01-16 | 350 | 13845 | 5 | |
FunnySaltyFish | - | 学生 | - | 2020-08-10 | 874 | 2366 | 4 | |
灵扁扁 | 一个普通程序员,努力上进,也想,活在当下。 | 一线开发 | - | 2022-03-31 | 276 | 18595 | 5 | |
南城FE | 公众号:南城大前端(ID: nanchengfe),分享前端相关技术干货 | 前端 | 深圳 | 2022-04-28 | 248 | 3722 | 4 | |
drinkwd | - | web前端工程师 | 小小小公司 | 2021-02-18 | 682 | 2468 | 4 | |
我犟不过你 | 摸鱼超级高水平 | java | 摸鱼更文 | 2021-08-13 | 506 | 12169 | 5 | |
马克付 | 从小白到大师的路上,有前端方面多年经验,CSDN/掘金/阿里云社区等平台优质作者,擅长工程化及性能优化技术,建立全网最强 开发者联盟群 都是开发者,欢迎技术交流 | 进阶者 | - | 2020-12-18 | 744 | 3990 | 4 | |
一条小尾鱼 | 我的心中有一只大鱼,它叫嚣着梦想和远方。 | - | 前端 | ν | 2021-01-04 | 727 | 321 | 3 | |
昆吾kw | 前端小趴菜。 | 前端 | - | 2022-07-12 | 173 | 3530 | 4 | |
dudoit | - | - | - | 2021-07-26 | 524 | 407 | 3 | |
前端lucio | 去码头搞点薯条 | 前端 | 腾讯 | 2021-07-08 | 542 | 3622 | 4 | |
努力的IT小胖子 | 喜欢做一些放松的事情,比如 听歌,看综艺,看书 | Java初级程序员 | - | 2021-04-17 | 624 | 5848 | 5 | |
西瓜watermelon | - | - | - | 2020-10-28 | 795 | 7706 | 5 | |
小黄瓜没有刺 | 😳 | FP | FE | - | 2019-07-29 | 1252 | 3201 | 4 | |
幻斌 | - | - | - | 2022-09-17 | 106 | 117 | 2 | |
树洞r00七 | - | 掘金摸鱼办 | 稀土掘金 | 2021-05-12 | 599 | 403 | 3 | |
braveMan | 选择比努力更重要,观念比选择更重要 | 前端工程师 | - | 2022-07-27 | 158 | 2980 | 4 | |
搭嘎撒搭嘎 | - | 后端开发 | - | 2022-06-09 | 206 | 113 | 2 | |
我是紫菜苔 | - | 前端@西安 | - | 2019-04-04 | 1368 | 2167 | 4 | |
老刘童鞋 | - | - | - | 2021-12-21 | 376 | 38 | 1 | |
最爱CiCi鸭鸭鸭 | - | - | - | 2022-06-03 | 212 | 10 | 1 | |
稀土君 | 挖掘最优质的互联网技术 https://juejin.cn ,经常搞活动搞抽奖,快关注快关注 | 最酷的 | 稀土 | 2015-04-09 | 2824 | 248826 | 8 | |
Zhujiang | 《Jetpack Compose:Android全新UI编程》作者,公众号:江江安卓 | 《Jetpack Compose:Android全新UI编程》 | 联想 | 2020-04-10 | 996 | 7172 | 5 | |
架构悟道 | 多年软件开发与系统架构经验,一起聊聊软件开发技术、系统架构技术、以及程序员最真实可行的职场打怪技能,代码之外的生存软技能。 | 架构师 | 🏆掘金签约作者 | 2020-03-07 | 1030 | 12532 | 5 | |
半岛铁盒里的猫 | 一个热爱唱歌、象棋、足球的90后程序员。 努力写出有趣、有故事感的博客。 | 🏆掘金签约作者 | 腾讯音乐 | 2020-02-18 | 1048 | 2539 | 4 | |
任侠 | 事在人为 | 前端开发 | gf | 2017-02-10 | 2151 | 3688 | 4 | |
咖妃 | - | 前端工程师 | 某教育公司 | 2022-01-06 | 360 | 1056 | 3 | |
头发尚在 | - | - | - | 2022-12-09 | 23 | 70 | 2 | |
兔子加油 | 好想吃兔子 | 兔子饲养员 | 小白兔公司 | 2022-07-24 | 161 | 250 | 2 | |
捂耳听枫 | - | 前端实习工程师 | 北京某科技有限公司 | 2022-09-13 | 110 | 151 | 2 | |
程序员追风 | Java技术学习分享 | 公众号:程序员追风 | - | 2019-08-08 | 1242 | 39361 | 6 | |
周小末天天开心 | 🌄 | - | 山东外事职业大学 | 2022-11-11 | 51 | 744 | 3 | |
云剪者 | 这是世界上你会遇到很多事,你只要做到不后悔就行了 | 程序员 | - | 2018-09-29 | 1555 | 1078 | 3 | |
南方者 | 南方者,一个热爱计算机,更热爱祖国的南方人。 (联系微信NanFangZhe404) | 程序员南方者 @微信公众号 | - | 2021-10-22 | 436 | 5388 | 4 | |
岛上码农 | 从南飘到北,从北游到南的业余码农 | 公众号 | 岛上码农 | 掘金签约作者🚩 | 2021-02-27 | 673 | 24145 | 5 | |
普罗米拉稀 | iOS Flutter 前端, 哪里不会点哪里 | 移动端开发 | - | 2021-12-15 | 382 | 571 | 3 | |
sweetying | Android,Flutter,Web,专注自我技术提升 | 公众号 @ sweetying | - | 2021-01-10 | 721 | 6726 | 5 | |
Sapper | 前端工程师 | - | 2022-03-22 | 285 | 1205 | 3 | ||
unidentifiable | 公众号『Java全栈路线』,获取计算机相关书籍 | 后端小菜鸡 | - | 2021-01-23 | 708 | 5296 | 4 | |
小饶同学 | 做饭,旅游,运动 | UFO | 某公司 | 2022-11-10 | 52 | 11 | 1 | |
地霊殿__三無 | - | 前端 | - | 2022-05-02 | 244 | 934 | 3 | |
小鑫同学 | 所有付出都将是沉淀,所有美好终会如期而至 | 🇨🇳深耕一线 | IT200.CN | 2020-05-27 | 949 | 11407 | 5 | |
i东东 | 人生海海,有帆有岸! | 新时代农民工 | - | 2021-12-09 | 388 | 2002 | 4 | |
Js_x | 去做风吧,做不被定义的风。 | 学生 | - | 2022-10-01 | 92 | 825 | 3 | |
xincheng_q | 擅长倾听、会坚持有意义的事情,喜欢旅游,吹风,摸鱼。 | - | - | 2022-07-23 | 162 | 1158 | 3 | |
Jack魏 | 在这个物质横欲的世界做一些自己喜欢觉得有趣的事情 | Java工程师 | 杭州蜂荟信息技术有限公司 | 2021-08-05 | 514 | 1052 | 3 | |
朝朝mumu | ~ Spark Hudi JanusGraph AEP ElasticSearch Hadoop Openlookeng ~ | 大数据架构师 | 郑州 | 2019-09-02 | 1217 | 2450 | 4 | |
狂砍2分4篮板 | 生活总要有点叛逆精神 | 前端工程师 | 广州才华有限公司 | 2020-07-11 | 904 | 10556 | 5 | |
点点VS叉叉 | 热爱着普通、平凡、简单的纯粹 | 前端切图仔 | - | 2022-04-13 | 263 | 3233 | 4 | |
Hello_Tom | 擅长带薪摸鱼、到点跑路等技能 | 下水道级后端工程师 | - | 2020-06-20 | 925 | 802 | 3 | |
伊人a | 前端面试有个很好的公众号推荐给大家☛前端面试官☚ 爱玩游戏、爱生活、爱技术、爱自己。 | 打野无敌 | 王者峡谷 | 2020-06-03 | 942 | 27659 | 5 | |
Aion_Liu | 程序开发 | 数据治理工程师 | - | 2021-08-05 | 514 | 810 | 3 | |
Morakes | Welcome to my blog, please feel free to leave a message if you have any questions, I will reply in time, yo! | Champion contestant | - | 2021-12-06 | 391 | 2507 | 4 | |
随风丶逆风 | - | 前端 | - | 2020-01-17 | 1080 | 2302 | 4 | |
CatWatermelon | 🐱🍉 | 公众号 | 前端喵瓜酱 | 2020-03-15 | 1022 | 8435 | 5 | |
酿酒的王同学 | - | - | - | 2022-08-18 | 136 | 753 | 3 | |
葱花儿 | coding | 工程师 | - | 2022-02-10 | 325 | 10 | 1 | |
IT技术分享社区 | 后端程序员,微信 hgmyzhl,公众号: IT技术分享社区 | 开发工程师 | 苏州海固科技 | 2017-10-14 | 1905 | 4008 | 4 | |
敲代码的小菜鸡 | Q | web前端 | 不知名小厂 | 2020-01-20 | 1077 | 627 | 3 | |
GleenLey | 保持热爱 真理无限 | - | - | 2021-08-01 | 518 | 982 | 3 | |
初念初恋 | 希望努力的每一个人坚持并快乐着。 | 公众号 | 初念初恋 | 2020-09-28 | 825 | 12072 | 5 | |
宁在春 | 望别日,与君相见时,君已有所成。 邮箱:nzc_wyh@163.com | 👨💻 | Java | 2021-07-27 | 523 | 12378 | 5 | |
前端摸鱼儿 | 无论如何记住一件事,不要逼自己学习,当你在某一节学习过程中感觉到容易分神时,那就是时候休息了,站起来活动下身体,打开窗户呼吸下新鲜空气,我会一直在这里等你回来。 | 前端 | … | 2021-01-06 | 725 | 3004 | 4 | |
镰刀刮腋毛 | - | - | - | 2022-06-28 | 187 | 10 | 1 | |
金克丝的含义就是金克丝 | - | - | - | 2021-08-08 | 511 | 34 | 1 | |
avion | 我观诸君皆装逼,料诸君看我应如是 | 摸鱼区潜水员 | - | 2022-06-01 | 214 | 3634 | 4 | |
添财青年 | Be a better me ^_^ | 前端开发工程师 | - | 2021-09-23 | 465 | 1029 | 3 | |
是乃德也是Ned | 努力成为更好的自己! | 公众号「前端成长日记」 | - | 2021-07-26 | 524 | 6851 | 5 | |
海阔_天空 | 编程如逆水行舟 不进则退 | 前端全栈开发 | - | 2020-09-30 | 823 | 17284 | 5 | |
格斗家不爱在外太空沉思 | 什么BUG?那是我设计的彩蛋 | 实习小生 | - | 2022-07-28 | 157 | 2679 | 4 | |
猪猪侠1号 | - | - | - | 2022-04-03 | 273 | 46 | 2 | |
草帽Plasticine | - | - | - | 2022-04-14 | 262 | 4762 | 4 | |
格心派 | 人间巡阅使——穷人首席体验官; | React | 布调科技 | 2018-01-04 | 1823 | 2450 | 4 | |
哇蓝蓝 | 世界既不黑也不白! | 啥也不是 | 暂无 | 2022-05-05 | 241 | 251 | 2 | |
小郭的技术笔记 | 领导,你能不能硬一点? | 高级Java开发工程师 | - | 2020-11-08 | 784 | 6622 | 5 | |
Jere_Chen | 如果你发现我的文章有错误,请毫无保留的指出,谢谢。因为这正是我写文章的目的,虚心请教👨💻 | Farmer & Software Engineer | - | 2020-01-21 | 1076 | 2838 | 4 | |
Yj家的孺子牛 | 在学习Android,希望不要毕业即失业的学生。 热爱分享,欢迎star | Android 开发 | 广东工业大学 数智工作室 | 2022-07-24 | 161 | 1167 | 3 | |
大黄鱼 | 上班?摸鱼才是王道 | 前端工程师 | 不知名小公司 | 2021-03-03 | 669 | 830 | 3 | |
江昪 | 谢谢你代码写的这么好,还关注我。 | 鼓励师 | 掘金 | 2015-05-06 | 2797 | 43996 | 6 | |
Loners | - | Bug开发者 | - | 2021-09-07 | 481 | 163 | 2 | |
程序员阿山哥 | Blog:https://codersamz.github.io 前iOS辣鸡开发,Swift练习生,Flutter练习生 | iOS渣渣 | 广州 | 2018-05-30 | 1677 | 371 | 3 | |
season_zhu | Swift/OC/Flutter/Python/Vue | 大前端API调用工程师 | Otaku | 2020-07-08 | 907 | 9689 | 5 | |
Halifax | 星光不问赶路人,岁月不负有心人 | Android @ 微信号: fuqiang2020 | - | 2018-06-22 | 1654 | 4216 | 4 | |
木木止月 | - | 学生 | - | 2022-02-25 | 310 | 3219 | 4 | |
什么时候能中奖 | - | - | - | 2022-10-19 | 74 | 10 | 1 | |
前端秀 | 汲取日常中的奥秘,吐露冰雪般的凝思 | 大前端 | baidu | 2021-12-31 | 366 | 437 | 3 | |
equationl | 非科班出身的程序猿,在流水线打了三个月螺丝后怒而提桶做安卓开发 | - | - | 2022-07-20 | 165 | 2479 | 4 | |
踏风无痕彡 | 热爱编程,热爱生活。 | - | - | 2022-11-27 | 35 | 350 | 3 | |
丘山子 | 一个没有真才实学的男孩。文质彬彬又如何,学富五车又怎样,若不能因真理而得自由,因真相而得分享,知识越多反而越昏庸。 | 编辑\产品\运营\技术 | - | 2021-03-11 | 661 | 8372 | 5 | |
Java白羊 | 最一本正经的摸鱼高手,最专业的划水博主 | Java开发工程师 | - | 2022-03-30 | 277 | 2632 | 4 | |
Z_Joker | 生活百般滋味 人生需要笑对 | cv工程师 | 家里蹲网络信息服务有限公司 | 2022-02-21 | 314 | 208 | 2 | |
AlanHou | - | - | - | 2022-01-13 | 353 | 1438 | 3 | |
山与路 | - | - | - | 2022-08-24 | 130 | 1740 | 3 | |
李三十一 | 大数据、内容挖掘、算法服务 | 🏆后端技术 | 公众号:李三十一 | 2021-02-22 | 678 | 1772 | 3 | |
蜡笔小心_ | 前端小学生,偶尔玩一点跨端技术 | 公众号『猿来是前端』 | - | 2021-12-28 | 369 | 4424 | 4 | |
Jokerrr | - | 前端小学生,Varlet | 无锡某公司 | 2021-12-01 | 396 | 6616 | 5 | |
DYBOY | 公众号:DYBOY | 前端开发 | 字节跳动 | 2021-03-12 | 660 | 4489 | 4 | |
小诸不是小猪 | :3 | 学生 | - | 2021-02-10 | 690 | 2133 | 4 | |
阆坞村小废物 | - | - | - | 2022-09-02 | 121 | 12 | 1 | |
二郎神杨戬 | 前端摸鱼师,前端劝退师,前端打杂师,哈啰单车爱好者 | web前端开发 | 某不知名互联网公司 | 2020-03-01 | 1036 | 1593 | 3 | |
丨隋堤倦客丨 | 我挥舞着键盘和本子,发誓要把这世界写个明明白白!!! | 前端工程师 | 某外企 | 2018-01-12 | 1815 | 3278 | 4 | |
一只小趴菜 | 此生还不曾去过倒悬山,看过北凉雪… | 前端工程师 | 趴菜聚集营 | 2022-07-28 | 157 | 790 | 3 | |
Mondo | Just do it. | BUG工程师 | imondo.cn | 2019-05-21 | 1321 | 2860 | 4 | |
网上冲浪不靠岸 | 一名来自世界上最好的国家正在进行秃头活动的青年~ | 前端 | - | 2021-12-30 | 367 | 537 | 3 | |
Benbinbin | - | - | - | 2020-02-22 | 1044 | 5090 | 4 | |
kaliarch | Devops,python,go,shell,云原生,云架构,kubernetes | Devops | anchnet | 2019-01-09 | 1453 | 13290 | 5 | |
沐阳不暮雪 | - | - | - | 2022-11-20 | 42 | 535 | 3 | |
free46000 | - | Android | 去哪儿网 | 2017-02-18 | 2143 | 2956 | 4 | |
heart_6662 | 生物信息学 深度学习 数据挖掘 领域爱好者 | 普通人 | - | 2021-12-31 | 366 | 2425 | 4 | |
zkj | 💁❤ | 全栈 | - | 2022-07-13 | 172 | 5309 | 4 | |
前端历劫之路 | 一个正在努力成长的前端工程师;开源MVVM框架Strve.js作者 | 前端历劫之路 | 公众号 | 2020-01-30 | 1067 | 11406 | 5 | |
灰色皮卡丘 | 希望最初你的就懂得“一本书阅读几遍,都不会改变已经书写的结局” | Java | Tom&Jerry | 2022-02-28 | 307 | 54 | 2 | |
Jioho | - | 前端工程师 | - | 2021-07-20 | 530 | 1498 | 3 | |
Tusi | 写代码,最重要的是开心 | 🏆掘金签约作者 | 长沙 | 2019-04-02 | 1370 | 17503 | 5 | |
君若雅 | 广场舞达人 | Java开发工程师 | - | 2021-06-24 | 556 | 911 | 3 | |
凉城a | 公众号:「前端面试官」 热爱技术也热爱生活 | 一个前端 | steam | 2019-08-05 | 1245 | 7596 | 5 | |
旋律丶 | - | 前端 | - | 2022-01-26 | 340 | 45 | 2 | |
劲风君 | 爬山、跑步、羽毛球 | Python开发工程师 | - | 2021-06-17 | 563 | 1771 | 3 | |
Camel | - | - | 公众号 | coder练习生 | 2022-05-03 | 243 | 2449 | 4 | |
dragonir | Accepted ✔ | computer programmer | - | 2021-03-18 | 654 | 12653 | 5 | |
AnLingYi | undefined | undefined | undefined | 2019-03-04 | 1399 | 3930 | 4 | |
程序猿杜小头 | 请搜索微信公众号:程序猿杜小头 | Java开发工程师 | 移动云 | 2022-02-19 | 316 | 676 | 3 | |
SteveCode | 微信公众号:SteveCode | Java垃圾工程师 | 工地搬砖互联网龙头科技有限公司 | 2022-04-09 | 267 | 621 | 3 | |
S_G | 不懂前端,浑水摸鱼的大二学生,梦想是进厂! | 戒骄戒躁,“平常”应对 | - | 2022-07-23 | 162 | 147 | 2 | |
潇雷 | 从事java开发。 当努力到一定程度,幸运自会不期而遇。 | 全栈+大数据 | - | 2020-06-15 | 930 | 7544 | 5 | |
有出路 | Talk is Cheap.The Coding Time! | - | 想要学好前端的有出路 | 2021-07-24 | 526 | 4412 | 4 | |
停留的亭 | - | - | - | 2022-04-06 | 270 | 62 | 2 | |
Eureka | - | 前端小白 | - | 2022-06-05 | 210 | 425 | 3 | |
OwenZhang | I actually hate programming, but I love solving problems. Phper & Gopher. https://my.oschina.net/owenzhang24 Email: owen@owenzhang.com | Phper & Gopher | Owen Internet Technology Co., Ltd. | 2019-12-17 | 1111 | 5829 | 5 | |
iskenhuang | - | - | - | 2022-08-22 | 132 | 53 | 2 | |
痒痒鼠苟策划 | Data Scientist? ❌ Frontend Engineer ✅ | Data Scientist | 家里蹲互联网科技有限公司 | 2020-02-29 | 1037 | 677 | 3 | |
我的代码果然有问题 | 一条咸鱼~ | 前端工程师 | 求捞 | 2018-05-16 | 1691 | 2393 | 4 | |
跟我一起秃秃秃 | 生命是一场奋斗! | 摸鱼工程师 | - | 2022-07-10 | 175 | 1236 | 3 | |
小码code | 不会做饭的程序员不是好程序员 | Java开发 | - | 2021-07-16 | 534 | 2777 | 4 | |
water | 前端开发 | 大前端 | - | 2019-12-03 | 1125 | 2969 | 4 | |
海的对岸 | Vue.js | 公众号:超哥在学习 | - | 2021-10-08 | 450 | 5521 | 5 | |
Captaincc | 寻找优质内容创作者ing 有任何关于掘金的问题可以咨询我微信:229199157 | 问题解决官 | juejin.cn | 2021-10-13 | 445 | 718 | 3 | |
前舟 | 计算机学生,学习(折腾)方向前端,主打的就是没那么书面化写作化输出文章🐶 欢迎一起学习交流~ 😎感谢关注~ | 前端 | 本科在读 | 2021-04-10 | 631 | 2981 | 4 | |
韩_师兄 | 业精于勤,荒于嬉;行成于思,毁于随。 | Java开发 | - | 2021-07-25 | 525 | 4620 | 4 | |
熊猫宝宝111 | - | - | - | 2022-08-08 | 146 | 10 | 1 | |
安余生大大 | - | - | - | 2021-07-18 | 532 | 3597 | 4 | |
阿柠xn | - | 兴趣使然 | - | 2022-07-21 | 164 | 2522 | 4 | |
凤2018 | - | - | - | 2022-09-16 | 107 | 10 | 1 | |
Tom弹架构 | 《Spring 5核心原理》、《Netty 4核心原理》、《设计模式就该这样学》作者,不只做一个技术者,更要做一个思考者 关注微信公众号『 Tom弹架构 』可获取更多技术干货! | Java架构丛书作者 | 公众号Tom弹架构 | 2021-10-19 | 439 | 8929 | 5 | |
雨夜之寂 | 不积跬步无以至千里,不积小流无以成江海 | Java工程师 | - | 2022-04-18 | 258 | 3053 | 4 | |
5加H | - | 前端代码工 | - | 2020-10-21 | 802 | 1271 | 3 | |
小麦_gz | 今天的砖,格外的烫手。 | 前端开发 | 梦想是成为包工头的搬砖人员 | 2020-03-19 | 1018 | 258 | 2 | |
熙宁 | - | Java 全栈小工 | - | 2022-01-18 | 348 | 504 | 3 | |
潘小七 | 大三在校大学生 | - | - | 2022-07-05 | 180 | 1527 | 3 | |
小小愿望 | 记录生活中点点滴滴有趣的事 | 前端工程师 | - | 2022-08-24 | 130 | 809 | 3 | |
阿杰笔记 | - | 数据&AI | - | 2022-09-24 | 99 | 624 | 3 | |
一碗周 | - | 前端造梦师 | - | 2020-11-14 | 778 | 22561 | 5 | |
不会编程的小虎 | 心若没有栖息的地方,到哪里都是流浪 | CV大师 | - | 2021-08-24 | 495 | 52 | 2 | |
捶捶自己 | 大二蒟蒻 | - | - | 2022-05-02 | 244 | 511 | 3 | |
Sjrjfj | 职业法师 | 中单 | - | 2022-09-03 | 120 | 10 | 1 | |
爱生活的胖崽 | - | 前后端都不开发 | 摸鱼第一名 | 2022-08-22 | 132 | 97 | 2 | |
雾与晨 | - | 非著名公司非专业前端实践者 | - | 2020-11-04 | 788 | 320 | 3 | |
前端工程狮JJ | - | 前端开发 | - | 2022-11-09 | 53 | 10 | 1 | |
小忠呐 | 简简单单就好 | java后端开发 | - | 2020-09-09 | 844 | 1289 | 3 | |
恋猫de小郭 | 《Flutter 开发实战详解》作者,Github GSY 系列项目负责人,一个写代码的老二次猿 | Flutter & Dart GDE | 🏆 掘金签约作者 | 2016-11-15 | 2238 | 82597 | 7 | |
不近视的猫 | 知其然并不知其所以然 | 搬砖工 | 无名小厂 | 2021-03-21 | 651 | 2445 | 4 | |
爱吃鱼的桶哥Z | 努力前行,不负时光☆ | 伪 · 全栈打杂攻城狮 | - | 2021-08-26 | 493 | 7199 | 5 | |
imber | - | 前端 | 搬砖 | 2021-10-22 | 436 | 829 | 3 | |
oSHYo | - | 前端er | - | 2019-06-16 | 1295 | 67 | 2 | |
盼小辉丶 | - | - | - | 2021-10-13 | 445 | 7890 | 5 | |
阿萨聊测试 | 双一流学校毕业,互联网测试 | 打杂的 | - | 2022-03-19 | 288 | 1818 | 4 | |
我上去直接刮痧 | - | 前端打字员 | 成都某摸鱼公司 | 2022-12-07 | 25 | 82 | 2 | |
fairyly | web 前端工程师,Node、Egg、Vue、React、 微信支付宝小程序 | web 前端工程师 | - | 2018-07-29 | 1617 | 2471 | 4 | |
左耳咚 | ฏ๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎ | 前端开发工程师 | - | 2021-12-09 | 388 | 642 | 3 | |
郑州小张 | - | web前端 | - | 2022-04-17 | 259 | 174 | 2 | |
高等海贼王 | - | - | - | 2022-11-22 | 40 | 11 | 1 | |
小柳666 | 谢谢你长那么好看,还给我点赞 | php全栈工程师 | 北京慧珠网络科技有限公司 | 2021-12-20 | 377 | 1876 | 4 | |
灵沉 | 点赞小能手帮我赞一下文章, 有赞必回 | java | H3C | 2022-11-11 | 51 | 727 | 3 | |
鸩书n1 | - | - | - | 2022-09-30 | 93 | 100 | 2 | |
songF | - | - | - | 2022-05-10 | 236 | 194 | 2 | |
胡哥有话说 | 公号「胡哥有话说」作者,大前端技术领域探索者 | 公众号 | 胡哥有话说 | 2019-07-24 | 1257 | 7035 | 5 | |
旺仔米苏 | - | 前端 | - | 2021-12-31 | 366 | 6379 | 5 | |
前端小白ya | HTML5 CSS3 Bootstrap JavaScript ES6 Vue 找工作中 | 前端工程师 | - | 2022-08-09 | 145 | 22 | 1 | |
juicesoo | goland,spass数据分析,短视频运营剪辑前后期,html,css,c,Java,etc | - | 一个会跳动的公司 | 2022-05-07 | 239 | 190 | 2 | |
断律绎殇 | 前acm打铁选手,现全栈搬砖社畜 | 全栈 | 活动阁 | 2022-01-29 | 337 | 5074 | 4 | |
井柏然 | 可以不会,不能不学。 | 广州井柏然 @ FE | - | 2019-03-08 | 1395 | 9948 | 5 | |
小帅不太帅 | 前端小码农 | 前端 | 公众号【前端小帅】 | 2020-09-27 | 826 | 3700 | 4 | |
Ichmag | - | 毕业倒计时 | - | 2019-04-02 | 1370 | 3476 | 4 | |
张拭心 | wx: remembergodblessyou 公众号:拭心又在思考了我的天(搜索“又在思考了”即可) | 打杂 | 上海 | 2016-07-26 | 2350 | 14721 | 5 | |
smallfish | 一个热爱代码,平平无奇的码农 | 前端 | - | 2021-10-28 | 430 | 214 | 2 | |
Jerry815 | - | iOS、Flutter | - | 2021-07-09 | 541 | 394 | 3 | |
柏炎 | 热爱hiphop,热爱酒精 | 🏅掘金签约作者 | 柏炎大叔 | zoom.us | 2020-02-16 | 1050 | 7166 | 5 | |
hook | - | FE | hook company | 2019-12-19 | 1109 | 35 | 1 | |
魔术师卡颂 | - | 加我vx:kasong999 | 拉你进「高质量前端框架群」 | 2020-04-15 | 991 | 22352 | 5 | |
wangpeng1478 | 前端开发 | web前端开发 | 家里蹲 | 2020-07-27 | 888 | 3014 | 4 | |
前端小溪 | 前端小溪@公众号 | 前端 | 不知名公司 | 2021-01-08 | 723 | 5800 | 5 | |
_小九 | 理想主义的花,最终会盛开在浪漫主义的土壤里,我的热情永远不会熄灭在现实的平凡之中,我们终将上岸,阳光万里。 | 🏆 掘金签约作者 ● 前端开发 | - | 2019-09-24 | 1195 | 8029 | 5 | |
整天想死的鱼 | - | - | - | 2022-03-20 | 287 | 145 | 2 | |
掘金产品经理 | 工欲善其事必先利其器: https://juejin.cn/extension https://code.juejin.cn | 码上掘金|插件|闪念笔记|内容分发 | 掘金社区 | 2021-04-14 | 627 | 518 | 3 | |
鲸落_ | - | - | - | 2021-03-14 | 658 | 1178 | 3 | |
程序员小杰 | 种一棵树最好的时间是十年前,其次是现在 | 公众号:程序员小杰 | - | 2021-04-28 | 613 | 8297 | 5 | |
云层上的光 | 我的社区名叫云层上的光,来自湖南长沙。花名初心,不忘初心的意思。 | 开会工程师 | - | 2022-02-18 | 317 | 333 | 3 | |
Serenade | 计算机爱好者 | coding | 待业 | 2021-11-01 | 426 | 1757 | 3 | |
苏苏同学 | 不积跬步,无以至千里;不积小流,无以成江海。 | 前端开发 | 上海医疗质量研究中心 | 2020-01-09 | 1088 | 8801 | 5 | |
凌览 | 会当凌绝顶,一览众山小 | 关注@凌览社 | - | 2021-07-01 | 549 | 1192 | 3 | |
小恒恒 | 最遗憾的事情最遗憾,最擅长的事情最擅长。 | 码农 | - | 2021-11-24 | 403 | 454 | 3 | |
剑圣无痕 | 架构师 | 剑圣 | - | 2021-07-16 | 534 | 6661 | 5 | |
秒写二叉树 | 一个热爱编程的在校大学生。阿里云官方认证专家博主 | @掘金@校园大使KeyPlayer | - | 2022-07-24 | 161 | 1168 | 3 | |
LH_R | keep learning… | 前端 | undefined | 2021-07-24 | 526 | 216 | 2 | |
Dignity_呱 | 专注前端,兼后端运维美术打杂人~有朋自远方来,不亦乐乎呀 | 关注@深夜末班车 | - | 2020-03-22 | 1015 | 7003 | 5 | |
CN千石 | 一个喜欢哲学、二次元の某不知名Gopher To be better! | 某不知名のGopher | - | 2022-07-25 | 160 | 239 | 2 | |
前端爆冲 | 前端/乒乓球,https://github.com/brenner8023 | 前端工程师 | sxf | 2019-12-02 | 1126 | 1202 | 3 | |
Bobbbbbb | - | 前端 | - | 2019-05-01 | 1341 | 157 | 2 | |
浅羽技术 | 才疏学浅,习习而为,编程羽录,与你同行。 | 🏆掘金作者 | 微信搜:浅羽的IT小屋 | 2020-06-22 | 923 | 3940 | 4 | |
YaYa | 遇到问题,解决问题,记录问题 | - | - | 2021-07-17 | 533 | 763 | 3 | |
申小兮 | 小兮要起床写代码啦! | - | - | 2022-07-19 | 166 | 655 | 3 | |
星河之码 | 公众号:星河之码 | 互联网 | 公众号:星河之码 | 2022-04-05 | 271 | 627 | 3 | |
前端小同学 | - | 前端配置砖家 | - | 2021-04-18 | 623 | 1535 | 3 | |
HXYDJ | 单片机、嵌入式、C语言 | 嵌入式开发 | - | 2021-04-30 | 611 | 4522 | 4 | |
手可摘棉花 | 吃货一枚,前端菜鸟 | 前端开发 | - | 2021-09-13 | 475 | 1681 | 3 | |
野林 | The Intersection of Technology and Liberal Arts | 前端工程师 | 中国联通 公众号:维李设论 | 2019-09-13 | 1206 | 2468 | 4 | |
xphjj | - | - | - | 2020-03-25 | 1012 | 1874 | 4 | |
刻意思考 | 找准方向,持续输出 | 码农 | 互联网 | 2021-12-27 | 370 | 1226 | 3 | |
落叶小小少年 | 专注于JS,框架学习 | 前端工程师 | - | 2020-01-01 | 1096 | 819 | 3 | |
小明同学尽力 | - | - | - | 2022-09-09 | 114 | 32 | 1 | |
前端禁止场所 | js、vue、ts | 摸鱼爱好者 | - | 2021-11-17 | 410 | 209 | 2 | |
马铃薯大象头 | - | 前端工程师 | - | 2022-07-10 | 175 | 173 | 2 | |
水冗水孚 | 生活不易,我们共同努力 | 前端开发 | 加油鸭 | 2021-01-22 | 709 | 8905 | 5 | |
CS_Joe | 那天是你用一块红布,蒙住我双眼也蒙住了天 | 前端 | 动画 | Three.js | - | 2018-10-09 | 1545 | 3122 | 4 | |
爱划水de鲸鱼哥 | 一个自由生长的野生程序猿 | 前台端菜工程师 | 某神仙单位 | 2022-04-14 | 262 | 2467 | 4 | |
凌晨三点半。 | - | 前端 | - | 2020-06-01 | 944 | 63 | 2 | |
六脉神剑 | 种一棵树最好的时间是十年前,其次是现在 | 欢聚YY@Java开发工程师 | 微信搜:六脉神剑的程序人生 | 2019-11-23 | 1135 | 16711 | 5 | |
我是绿色大米呀 | - | Android搬砖人 | 教小朋友说话公司 | 2017-04-23 | 2079 | 5797 | 5 | |
浅辄 | 阿里云专家博主 乘风问答官 野生大数据开发一枚 | - | - | 2022-11-26 | 36 | 1007 | 3 | |
似曾相识2022 | 黄昏的另一端 | Android | - | 2022-07-20 | 165 | 62 | 2 | |
淹死的鱼r | - | 前端开发工程师 | 摸鱼公司 | 2022-07-16 | 169 | 173 | 2 | |
香菜_香菜 | 写了十来年的代码,当过小兵,创过业, 公众号:香菜聊游戏,关注我,有干货和游戏源码哦,带你走进游戏圈 | 公众号:香菜聊游戏 | - | 2021-05-13 | 598 | 3571 | 4 | |
前端阿彬 | 致力于前端知识关联归纳总结~ 之前一直是在CSDN写博客,但是看掘金,现在准备把之前的文章慢慢转移过来,并且以后在掘金发文啦,一次性复制工作量太大,慢慢来叭~ | super 赛亚人 | - | 2021-11-30 | 397 | 261 | 2 | |
candyTong | 公众号:Candy 的修仙秘籍 | 前端工程师 | 腾讯 | 2019-04-11 | 1361 | 3417 | 4 | |
魔天伦 | 前端学习ing 关注,点赞必回 | 前端web攻城狮 && 大二学生 | - | 2022-10-27 | 66 | 668 | 3 | |
Spirited_Away | 实习中… | 学生 | 名字带个电字 | 2020-05-14 | 962 | 7348 | 5 | |
知你故来风 | 知其然,然后知其所以然 | 前端工程师 | 杭州四大坑 | 2022-02-11 | 324 | 7606 | 5 | |
FESKY | 相信坚持的力量。 | 前端开发工程师 | TX | 2015-12-01 | 2588 | 23628 | 5 | |
德育处主任 | 😼可爱又迷人的反派保安 | 🛠️打杂 | - | 2020-11-07 | 785 | 20771 | 5 | |
Layer | - | 抖音 | 字节跳动 | 2021-04-19 | 622 | 1214 | 3 | |
路人高 | 路漫漫其修远兮,吾将上下而求索。 | 高级cv工程师 | - | 2022-01-24 | 342 | 109 | 2 | |
前端小乌龟 | 互相学习,互相帮助,互相分享 | 前端工程师 | - | 2021-10-27 | 431 | 2682 | 4 | |
叫苏珊的_ikun | 普通前端 | FE | 心脏跳动 | 2022-03-15 | 292 | 5756 | 5 | |
乔治_x | 我们必须习惯,站在人生的交叉路口,却没有红绿灯的事实 | 程序员 | - | 2019-05-18 | 1324 | 5138 | 4 | |
我不吃饼干 | 心情不好的时候就不写分号 | 前端 | 虾皮 | 2019-02-04 | 1427 | 4344 | 4 |
一年过去了,相比去年的创作者榜单,会发现大多数创作者依然还在坚持,也有一些新人加入,让技术分享更加动人。当我看到优秀文章内容的时候,总是欣喜若狂!那种感觉大家应该都体会过,所以,希望本文可以让大家能收获到一些优秀的创作者,学习到更多的干货,总结 2022,向优秀学习,勇敢向往 2022!
最后,感谢掘金举办的这次活动,让开发者欢聚一堂,同时也让活跃的开发者呈现在大家面前,正如掘金去年活动页面写的:
相信技术,传递价值,这是掘金每一个技术创作者的动力与信念。
他们分享前沿的技术创新,输出最佳的生产实践,影响着每一个上进的开发者
注:本文首发于 iHTCboy’s blog,如若转载,请注来源。
本文首发于 使用 App Store Connect API 批量创建内购商品 - 掘金,欢迎关注我们 @37手游iOS技术运营团队 。
作者:iHTCboy
我们去年开源 AppleParty(苹果派) 用于批量应用内购商品的创建和更新的方案,具体的技术方案是使用 XML Feed 格式来处理。而今年苹果在 WWDC22 宣布,2022 年 11 月开始,不再允许使用 XML 方式上传元数据和内购商品。
我们去年开源 AppleParty(苹果派) 用于批量应用内购商品的创建和更新的方案,具体的技术方案是使用 XML Feed 格式来处理。而今年苹果在 WWDC22 宣布,2022 年 11 月开始,不再允许使用 XML 方式上传元数据和内购商品。
苹果在 7 月公告 即将从 XML Feed 过渡到 App Store Connect API,并且一直邮件通知开发者,截止 11月 9 日之前:
1 | We noticed you recently used the XML feed to manage and deliver content to App Store Connect. As we wrote to you previously, as of November 9, 2022, you’ll need to use the App Store Connect REST API to manage in-app purchases, subscriptions, metadata, and app pricing. The XML feed no longer supports this content, but continues to support existing Game Center management functionality. |
如果现在还使用 XML feed 上传,会收到以下告警:
1 | ERROR ITMS-6036: "XML schemas software5.12 and earlier have been deprecated and uploads of app metadata, in-app purchases, and subscriptions are no longer supported through the XML feed. You can use the App Store Connect API instead. |
所以,XML feed 禁止上传的内容:
而 Game Center
和上传 ipa
文件等方式,目前还能上传,目前来看,是因为 App Store Connect API 还不支持!所以,希望明年 WWDC23 苹果能支持上传 ipa 文件,这样就更加方便~
App Store Connect API 需要生成密钥才能调用使用,所以,我们先来介绍一下密钥的生成,然后在以应用内购商品的创建和更新为例,展示 API 使用示例。
生成密钥 ID(kid)和 Issuer ID(iss)
要生成密钥,您必须在 App Store Connect 中具有管理员角色或帐户持有人角色。登录 App Store Connect 并完成以下步骤:
“用户和访问” -> “密钥” -> “App Store Connect API” -> “生成 API 密钥”
注:访问权限:
根据密钥使用场景,访问的权限也不一样。要创建和管理 App 内购买项目,请确保您拥有以下用户角色之一:
详细权限,可参考文档 职能权限。
1、Issuer ID:拷贝复制内容
2、密钥 ID: 生成的密钥,有一列名为 “密钥 ID” 就是 kid 的值,鼠标移动到文字就会显示 拷贝密钥 ID,点击按钮就可以复制 kid 值。
3、API 密钥文件,下载 API 密钥 按钮(仅当您尚未下载私钥时,才会显示下载链接。),此私钥只能一次性下载!。
注意:将您的私钥存放在安全的地方。不要共享密钥,不要将密钥存储在代码仓库中,不要将密钥放在客户端代码中。如果您怀疑私钥被盗,请立即在 App Store Connect 中撤销密钥。有关详细信息,请参阅 撤销API密钥。
最终,生成以下参数和文件:
名字 | 值示例 | 说明 | 字段值说明 |
---|---|---|---|
密钥ID | GC8HS3SX37 | kid,Key ID,密钥ID | 您的私钥ID,值来自 API 密钥页面。 |
密钥内容文件 | SubscriptionKey_GC8HS3SX37.p8 | 密钥文件(p8) | 用来访问和使用 App Store Connect API 接口的服务。 |
Issuer ID | 69a6de92-xxx-xxxx-xxxx-5bc37c11a4d1 | iss,Issuer ID,发行人 | 您的发卡机构ID,值来自 App Store Connect 的 API 密钥页面。 |
这里我们使用 python3 创建 API 请求示例,需要依赖 jwt
和 requests
库,所以需要在终端安装:
1 | pip3 install jwt |
怎么请求 App Store Connect API ?苹果给出了一个示例:
1 | curl -v -H 'Authorization: Bearer [signed token]' |
也就是用 JWT 生成的 token,放到 App Store Connect API 请求链接的 header 部分,key 为 Authorization
,value为 Bearer [signed token]
。
接下来,我们通过 Python 的 requests
来请求 App Store Connect API。大家也可以用其它的工具来模拟,比如在线工具或者 Postman 等。
1 | import jwt |
接下来,以获取 app 列表为例,请求也非常简单:
1 | # 获取全部 app |
返回内容示例:
1 | { |
App Store Connect API 可以根据官方文档就能大概了解,但是依然非常难,就是 POST 接口的 body 和上传文件的流程。
POST body
以 Create an In-App Purchase 为例,请求的 body:
1 | { |
其中 inAppPurchaseType
可能为:
而订阅类型的商品,是另一个 API Create an Auto-Renewable Subscription,对应的请求的 body:
1 | { |
其中 subscriptionPeriod
可以为:
上传文件
上传文件的流程,刚开始看文档没有看明白,最后又仔细查文档才找到 Uploading Assets to App Store Connect,以上传应用内购买的送审图片为例,Create an In-App Purchase Review Screenshot,需要对应的请求的 body:
1 | { |
请求成功后,Response Code 为 201 时:
1 | { |
返回的响应内容 uploadOperations
中的 url 就是上传图片文件的请求 url,对应的 requestHeaders
也是组装 request 必备的 headers 属性,图片文件的大小要与 length 长度一致。
从上文就可以看出来,如果自己全部的 API 都实现一次,工作时是非常大,所以我们非常感谢 AvdLee/appstoreconnect-swift-sdk,使用 Xcode 的 Swift Package Manager 导入 https://github.com/AvdLee/appstoreconnect-swift-sdk.git
就可以使用!
以创建内购商品为例:
1 | func createInAppPurchases(appId: String, product: IAPProduct) async -> ASCInAppPurchaseV2? { |
这里就不再展开,详细可以参考我们开源项目代码:AppStoreConnectAPI.swift。
下载 2.1.0 更新版本:Releases · 37iOS/AppleParty
更新重点内容
表格格式更新,删除无法字段,支持多种本地化语言:
支持多种本地化语言,通过在表格最后的列增加,本地化语言标识,每种语言增加2列,分别对应本地化的名字和描述。
内购列表更新支持不同的价格国家地区的价格显示:
导入表格后,首次需要设置 API 密钥:
密钥获取,参考本文的第二章内容。
提交后,会自动执行上传,如果存在的商品会更新内容,成功时:
App Store Connect API 功能非常多,包括元数据的管理,构建版本的管理、TestFlight 管理、证书管理等等,Apple Party(苹果派)从日常使用场景最多的内购商品批量创建入手,未来依然有非常多的生效力效率提升,欢迎大家一起迭代和 PR 提交!
欢迎你一起体验和参考 37iOS/AppleParty~
欢迎大家评论区一起讨论交流~
欢迎关注我们,了解更多 iOS 和 Apple 的动态~
]]>注:如若转载,请注明来源。
本文首发于 用 SwiftUI 实现 AI 聊天对话 app - iChatGPT - 掘金,欢迎关注我们 @37手游iOS技术运营团队 。
作者:iHTCboy
关于 ChatGPT 的话题,大家都不陌生,我们直入话题,因为 ChatGPT 目前限制中国访问服务,所以如果直接使用 ChatGPT 网页进行对话,还是不太方便。通过 ChatGPT SessionToken 就可以不限制网络访问,所以大家发挥想象力实现各种的聊天机器人、小程序,而原生 app 可能体验更好!所以就有了 iChatGPT!一款用 SwiftUI 实现的开源 ChatGPT app,欢迎大家关注和 pr。
关于 ChatGPT 的话题,大家都不陌生,我们直入话题,因为 ChatGPT 目前限制中国访问服务,所以如果直接使用 ChatGPT 网页进行对话,还是不太方便。通过 ChatGPT SessionToken 就可以不限制网络访问,所以大家发挥想象力实现各种的聊天机器人、小程序,而原生 app 可能体验更好!所以就有了 iChatGPT!一款用 SwiftUI 实现的开源 ChatGPT app,欢迎大家关注和 pr。
GitHub 开源地址:https://github.com/37iOS/iChatGPT
目前 v1.0.0,实现 ChatGPT 基本聊天功能:
支持系统:
首先,需要点击 app 右上角图标,添加 ChatGPT SessionToken
密钥才能使用,否则无法请求。
获取 SessionToken
的方法很多,其中浏览器方法:
command + option + I
)储存空间
选项卡)__Secure-next-auth.session-token
的值,添加到 app 后确认。iOS 操作的界面:
macOS 操作的界面:
使用 SwiftUI 大概几个小时就完成所有的工作,方便跟苹果生态实现。实现的难点就可能就是模拟 ChatGPT 请求过程。目前是根据 A-kirami/nonebot-plugin-chatgpt 项目中的 python 实现,用 Swift 重写了一次,而 ChatGPT 登陆暂时没有实现,大家可以提 pr。
最后封装的网络请求类 ChatGPT.swift
1 |
|
唯一可以说说的就是,ChatGPT 的 backend-api/conversation
接口返回的内容,为了实现一个连接打开的效果,返回了一堆的数据。例如一个回答是 "我无法确定全球当前的人口数量,因为我没有浏览网页的能力。"
,返回的内容是这样:
1 | data: {"message": {"id": "xxxx", "role": "assistant", "user": null, "create_time": null, "update_time": null, "content": {"content_type": "text", "parts": ["我"]}, "end_turn": null, "weight": 1.0, "metadata": {}, "recipient": "all"}, "conversation_id": "xxxx", "error": null} |
所以,需要按行分割,然后取倒数第四行的内容,再去掉 data:
字符才是我们想要的 json 内容。
1 | let lines = text.components(separatedBy: "\n") |
当然,目前 ChatGPT 还是 beta 阶段,所以暂时没有开放 API,后续如果提供 API,就会更加方便!
目前 ChatGPT 是 beta 免费使用阶段,未来 API 请求会收费,具体可参考 https://openai.com/blog。
ChatGPT 对话的个人头像,大家发现无法有 https://openai.com 上进行修改。因为目前使用的是 Gravatar 服务。
Gravatar,全称 Globally Recognized Avatar
。翻译成中文叫:全球通用头像。
Gravatar 的概念首先是在国外的独立 WordPress 博客中兴起的,当你到任何一个支持Gravatar的网站留言时,这个网站都会根据你所提供的Email地址为你显示出匹配的头像。当然,这个头像,是需要你事先到 Gravatar 的网站注册并上传的,否则,在这个网站上,就只会显示成一个默认的头像。
简单来说,就是头像链接为 https://s.gravatar.com/avatar/xxx
,其中 xxx
就是你登陆邮箱的 MD5 值,只要在 Gravatar 注册验证了这个邮箱,你就可以更新头像,或者任何人都可以获取你的头像,只要知道你的邮箱。详细可以参考:Image Requests - Globally
写一首诗,庆祝 iChatGPT app 开源:
1 | 咦,知道 iChatGPT |
直呼牛~
目前 iChatGPT 开源地址:https://github.com/37iOS/iChatGPT 。还有很多功能没有实现,比如:
欢迎大家提 PR !
另外,我们近期也会更新 AppleParty,更新苹果批量上传内购商品功能,敬请期待~
最后,大家觉得 ChatGPT
解决了什么痛点?有什么期待吗
欢迎大家评论区一起讨论交流~
欢迎关注我们,了解更多 iOS 和 Apple 的动态~
]]>注:如若转载,请注明来源。
本文首发于 WWDC22 - In App Purchase 更新总结 - 掘金,欢迎关注我们 @37手游iOS技术运营团队 。
作者:iHTCboy
WWDC21 是历年来 In App Purchase(IAP,内购内购买)最大变化的一年,分别推出了 StoreKit 2、App Store Server API、App Store Server Notifications V2 三大特性,去年我们也编写了 《苹果iOS内购三步曲:App内退款、历史订单查询、绑定用户防掉单!— WWDC21》 文章,所以我们本文不会再深入提及去年的更新,大家如果不太熟悉,可以先温习一下。本文将对今年 WWDC22 带来的变化,从整体的视角一起回顾。
WWDC21 是历年来 In App Purchase(IAP,内购内购买)最大变化的一年,分别推出了 StoreKit 2、App Store Server API、App Store Server Notifications V2 三大特性,去年我们也编写了 《苹果iOS内购三步曲:App内退款、历史订单查询、绑定用户防掉单!— WWDC21》 文章,所以我们本文不会再深入提及去年的更新,大家如果不太熟悉,可以先温习一下。本文将对今年 WWDC22 带来的变化,从整体的视角一起回顾。
以下是编者对 In App Purchase 这几年重要的更新或调整的梳理:
时间 | 事件 | 变化 | 来源 |
---|---|---|---|
2020 年 11 月 18 日 | App Store 小型企业计划 | 日历年收入在 100 万美元以下的小型和独立开发者将可以享受 15% 的佣金费率,仅为 App Store 标准佣金费率 30% 的一半,付费 app 和 App 内购买项目的收益抽成将降低 15%。 | 1、2 |
2020 年 11 月 23 日 | 针对在线多人活动的 app 内购买项目规定 | 3.1.3(d) 一对一服务:如果您的 App 允许购买两个人之间的一对一实时服务 (例如,学生辅导、医疗咨询、看房服务或健身训练),您可以使用 App 内购买项目以外的其他购买方式来收取相应款项。一对几和一对多的实时服务则必须使用 App 内购买项目。 | 1、2 |
2021 年 8 月 26 日 | Apple 与美国开发者就 App Store 达成和解 | 美国开发者提起的 App Store 集体诉讼与苹果和解,Apple 设立一亿美元的基金来帮助美国的小型业务开发者,符合条件的开发者获得 250 美元至 3 万美元的现金)。 | 1、2 |
2021 年 9 月 1 日 | 日本公平贸易委员会结束对 App Store 的调查 | 3.1.3(a) “阅读器”类型的 App:此类 App 可以允许用户访问先前购买的内容或内容订阅 (具体包括:杂志、报纸、图书、音频、音乐和视频)。各种阅读器 App 可以为使用免费版本的用户提供帐户创建功能,并为现有用户提供帐户管理功能。阅读器 App 开发者可以申请 External Link Account 授权,以在其 App 中提供一个指向其拥有或负责维护的网站的信息链接,以便用户创建或管理帐户。了解有关 External Link Account 授权的更多信息。 | 1、2 |
2022 年 1 月 14 日 | 针对在荷兰 App Store 上分发的约会 App 的更新 | 荷兰消费者和市场管理局(ACM)允许荷兰 App Store 上的约会 App 开发人员与用户共享额外的付款处理选项。允许仅在荷兰 App Store 中分发的约会 App 在 App 内提供其他支付处理选项。开发者可以使用 StoreKit 外部购买授权,苹果降低 3% 的佣金,可与小型企业计划或自动续期订阅的 15 %佣金叠加,最低抽成 12 %。 | 1、2 |
2022 年 5 月 16 日 | 自动续期订阅提价更新 | 目前,当自动续期订阅提价时,订阅者必须在 App 提价之前选择接受。新调整:符合某些特定条件并在提前通知用户的情况下,开发者在为自动续订订阅提价时,无需用户额外采取行动,亦不会中断服务。(前提条件:每年提价不超过一次,同时订阅价格上调不超过 5 美元和 50%,或者年度订阅价格上调不超过 50 美元和 50%,并且是在法律允许的范围内。) | 1、2 |
2022 年 6 月 30 日 | 针对在韩国分发 App 的更新 | 允许仅在韩国 App Store 中分发的 App 在 App 内提供其他支付处理选项。开发者可以使用 StoreKit 外部购买授权,但苹果收益抽成 26%。 | 1、2 |
说到内购,环绕着的新闻,总起到一些波澜,从 2021 年苹果推出 App Store 小型企业计划,降低 15% 的佣金,大家的讨论一直源源不断,对于小型企业和开发者,确实是明显感受到 15% 带来的回报!本文不去讨论合理性,App Store 从 2008 年推出就是一个创举,它改变了世界对 App 的认识。我们本文更多的是讨论如果利用这些变化,为用户提供更好的服务或体验!
本文主要从四方面进行探讨:
StoreKit 2 和 Original StoreKit,应该怎么选择?苹果在选择文档在给出了答案:
去年的文章,我们提到以下功能必须依赖 Original StoreKit API:
因此,今年的 StoreKit 2,苹果提供新的字段 preorderDate 和 originalPurchaseDate 来获取 App 预订时间和购买时间,但是只支持 iOS 16+。
所以,目前 iOS 16 和 StoreKit 2 不能解决的问题:
2022年,如何选择 Original StoreKit 还是 StoreKit 2
对于支持低于 iOS 15 以下 app 依然需要使用 Original StoreKit,直到只支持 iOS 15+,并且支持迁移到 StoreKit 2。对于目前开发者来说,使用 StoreKit 2 的成本主要是兼容的系统版本,还有一方面是服务端的兼容,最后是 app 如果有 IAP 服务,那一定是核心业务,不容许一点点的错误!这导致了大多数 app 还处于围观 StoreKit 2 的状态。对于只支持 iOS 15+ 或者独立开发者,建议可以尝试使用 StoreKit 2,如果有异常时,降级到 Original StoreKit 就可以。总之,最后等时间给我们答案吧。
StoreKit 2 增加了 App Transaction 结构体,用于代替 Original StoreKit 的 receipt 内容,具体直接查看接口文档:
1 | /// Represents signed transaction information for an app purchase. |
App Transaction
从以上接口可以获取 App 预订时间 preorderDate 和购买时间 originalPurchaseDate 等。另外,验证用户当前使用的 app 是否正品购买以防止欺诈的作用。
验证 App Transaction 的方法:
1 | @available(iOS 16.0, *) |
最后说明一下,App Transaction 的内容,首次启动时,StoreKit 会自动获取更新并保持最新状态。当您的 app 无法通过 shared
属性获得 App Transaction 时(包括返回 Verification.unverified(::) 或抛出异常错误),可以使用 refresh() 刷新 App 交易内容,但是刷新时,系统会弹窗提示用户可能需要重新授权认证 Apple ID 账号,所以建议是提供用户操作的按钮,由用户主动发起调用。
StoreKit 2 带来了新的四个字段:
Price locale
1 | extension Product { |
新增 priceFormatStyle 和 subscriptionPeriodFormatStyle 字段。一般情况下,苹果建议尽可能使用 displayPrice 字段表示格式。例如从 price 属性获取两个品项的价格,例如 2 products for $(
price * 2)
。
Server environment
1 | public struct Transaction : Identifiable { |
在 iOS 16+ 使用 environment 结构体,在 iOS 15 使用 environmentStringRepresentation 字段。
获取到的字段值:
环境 | 值 | 说明 |
---|---|---|
App Store | Production | App Store 商店包环境的交易 |
App Store Sandbox 或 TestFlight | Sandbox | Develop 或 TestFlight 环境的交易 |
Xcode StoreKit Testing | Xcode | 使用 Xcode 进行 StoreKit 测试的交易 |
Recent subscription start date
1 | extension Product.SubscriptionInfo { |
recentSubscriptionStartDate 表示自动续期订阅购买中订阅的最早开始日期,忽略了超过 60 天的所有续费失败的订阅。
需要注意的是,不要使用 recentSubscriptionStart 字段日期来计算付费服务天数,以前,自动续期订阅的净收入结构和 App Store 上的其他商业模式不同,用户订阅累积满一年后,开发者的 收入将增加到订阅价格的 85%。所以,开发者不能依据这个字段来判断用户订阅是否满一年。另外,如果开发者当前注册了 App Store Small Business Program,符合条件的情况下,无论订阅是否已累积满一年,其实在每个结算周期收到订阅价格的 85%。
Sentinel values
另外,在不支持的系统和环境中,就会使用 Sentinel values
哨兵值(占位符值),例如 Price local 下使用 Locale(identifier: "xx\_XX")
,而 Recent subscription start date 使用 Date.distantPast
等。这是为什么呢?
因为以上的字段,其它在 Xcode13 和 iOS 15 是不存在的!苹果利用 Xcode 14 提供了对 iOS 15, iPadOS 15, macOS 12, Mac Catalyst 15, watchOS 9, tvOS 15 等的支持。原理是通过 Xcode 14 编译 app 时,会带上这些字段在 app 包体中,低系统的用户更新包含这些字段的版本时,就能使用。(具体是怎么编译和实现,有懂的朋友欢迎留言交流,小编暂时还没有找到相关文档。)
另外,JWS Transaction 的 Payload 内也新增 environment、recentSubscriptionStartDate 相关字段,下文会提到。
针对 SwiftUI 增加了优惠代码兑换接口和应用内评分接口。
StoreKit Message API 只支持 iOS 16+,用于开发者在 app 中接收和显示 App Store 消息处理。举例来说,自动续期订阅的费用涨价时,如果需要用户确认同意涨价,就需要弹窗给用于确认:
具体的 StoreKit messages 交互流程图:
获取 App Store messages 消息,使用 SwiftUI 实现的代码示例:
然后显示 App Store messages 消息,需要通过 SwiftUI 环境变量 displayStoreKitMessage
来解析和显示,使用 SwiftUI 实现的代码示例:
1 | let payment = SKMutablePayment(product: product) |
applicationUsername 是 Original StoreKit 创建苹果订单时,由开发者赋值的一个字段,原本这个字段是传入用户 UID 的 Hash 值,作用是给苹果验证应用购买以防止欺诈,比如代充和黑产恶意充值等。
而 appAccountToken 是去年 WWDC21 推出 StoreKit 2 的一个字段,用于开发者将苹果交易与自己服务上的用户关联的 UUID 格式的字段。
而现在,苹果打通了 applicationUsername 和 appAccountToken,当用 Original StoreKit 创建订单时,applicationUsername 字段赋值使用 UUID 格式内容时,则可以在服务端通知或者解析 receipt 票据时,可以获取这个 UUID 值,也就是订单可以关联确认。
我们回顾一下,我们为什么需要使用 applicationUsername
?我们是希望每个交易 transaction 可以关联用户订单号,对于订阅类型和非消耗类型品项,关联用户 UID 就能满足需求,但是对于非消耗型品项,其实,需要关联用户 UID 还有订单号 OrderID,因为非消耗型品项可以重复购买并且没有 UID 的强关联。举例来说,游戏里的用户账号可能不止一个,或者一个账号下的游戏角色,通常不止有一个角色,所以购买非消耗型品项时,开发者希望关联的是当前用户 UID 和此角色 RoleID 生成的开发者订单号 OrderID,但此时,UUID 格式并不能满足开发者自定义的需求!
所以,applicationUsername 和 appAccountToken 的透传值,对开发者有一定的关联作用,但其实还不完美。
符合条件的 app 可以包含一个链接,引导使用该 app 的用户访问网站进行外部购买。要包含该链接,请完成此授权的请求。有关符合条件的 app 和请求此授权的更多信息,请参阅:
具体的细节这里不说,就重点说说代码。首先,需要更新 app 的 Info.plist 文件,添加权限:
配置示例:
1 | <key>com.apple.developer.storekit.external-purchase</key> |
然后就是接口调用,在 iOS 或 iPadOS 15.4 或更高版本,使用 StoreKit External Purchase API:
1 | @available(iOS 15.4, *) |
如图所示,按照苹果的规范,使用外部购买必须要的步骤:
在 iOS 和 iPadOS 15.4 运行的代码示例:
1 | // 当前设备不能支付,则不能进行购买~ |
注意事项:
I Understand
(我明白)后,才能跳转到第三方支付系统阅读器 App 是指将提供以下一种或多种数字内容类型作为其主要功能的 App:杂志、报纸、图书、音频、音乐或视频。
通过阅读器 App,用户可以登录他们在 App 之外创建的帐户,从而可以在用户的 Apple 设备上阅览和畅读先前购买的媒体内容或内容订阅。开发者可以提供指向 app 网站的链接,以便用户在 app 网站上创建和管理帐户。有关符合条件的 app 和请求此授权的更多信息,请参阅:
同理,首先,需要更新 app 的 Info.plist 文件,添加权限:
1 | <key>com.apple.developer.storekit.external-link.account</key> |
然后就是接口调用,在 iOS 或 iPadOS 16 或更高版本,使用 StoreKit External Link Account API:
1 | @available(iOS 16.0, *) |
如图所示,按照苹果的规范,使用外部购买必须要的步骤:
在 iOS 和 iPadOS 15.4 运行的代码示例:
1 | @available(iOS 16.0, *) |
注意事项:
Continue
(继续)后,才能跳转到外部网站进行帐户创建或管理App Store Server API
是苹果去年 WWDC21 推出的 ,详细可以参考我们之前的文章《WWDC21 - App Store Server API 实践总结》。
今年 WWDC22 苹果新增了三个新接口,并且对部分接口增加了过滤功能,这里我们列了一个表格:
推出时间 | 接口 | 说明 | 链接 |
---|---|---|---|
WWDC21 | Look Up Order ID | 查询用户订单的收据,使用订单ID从收据中获取用户的应用内购买项目收据信息。 | GET https://api.storekit.itunes.apple.com/inApps/v1/lookup/{orderId} |
WWDC21 | Get Transaction History | 查询用户历史收据,获取用户在您的 app 的应用内购买交易历史记录。 | GET https://api.storekit.itunes.apple.com/inApps/v1/history/{originalTransactionId} |
WWDC21 | Get Refund History | 查询用户内购退款,获取 app 中为用户退款的所有应用内购买项目的列表。 | GET https://api.storekit.itunes.apple.com/inApps/v1/refund/lookup/{originalTransactionId} |
WWDC21 | Get All Subscription Statuses | 查询用户订阅项目状态,获取您 app 中用户所有订阅的状态。 | GET https://api.storekit.itunes.apple.com/inApps/v1/subscriptions/{originalTransactionId} |
WWDC21 | Send Consumption Information | 提交防欺诈信息,当用户申请退款时,苹果通知(CONSUMPTION_REQUEST)开发者服务器,开发者可在12小时内,提供用户的信息(比如游戏金币是否已消费、用户充值过多少钱、退款过多少钱等),最后苹果收到这些信息,协助“退款决策系统” 来决定是否允许用户退款。 | PUT https://api.storekit.itunes.apple.com/inApps/v1/transactions/consumption/{originalTransactionId} |
WWDC21 | Extend a Subscription Renewal Date | 延长用户订阅的时长,使用原始交易标识符延长用户有效订阅的续订日期。(相当于免费给用户增加订阅时长) | PUT https://api.storekit.itunes.apple.com/inApps/v1/subscriptions/extend/{originalTransactionId} |
WWDC22 | Request a Test Notification | 测试 App Store 服务器通知,让 App Store 服务器通知向开发者服务器发送测试通知。 | POST https://api.storekit.itunes.apple.com/inApps/v1/notifications/test |
WWDC22 | Get Test Notification Status | 获取 App Store 服务器通知的测试结果,获取发送到开发者服务器的 App Store 服务器测试通知的检查状态。 | GET https://api.storekit.itunes.apple.com/inApps/v1/notifications/test/{testNotificationToken} |
WWDC22 | Get Notification History | 获取 App Store 服务器通知的历史通知,获取 App Store 服务器尝试发送到开发者服务器的通知列表。 | POST https://api.storekit.itunes.apple.com/inApps/v1/notifications/history |
其中只有 Get Transaction History 接口提供了过滤和排序的功能:
目前支持的查询参数列表:
查询参数 | 作用 | 可选值 |
---|---|---|
productType | 包含在交易历史记录中的产品类型。您的查询可以指定多个productType。 | AUTO_RENEWABLE, NON_RENEWABLE, CONSUMABLE, NON_CONSUMABLE |
productId | 包含在交易历史记录中的产品标识符。您的查询可以指定多个productID。 | - |
subscriptionGroupIdentifier | 包含在交易历史记录中的订阅组标识符。您的查询可能会指定多个subscriptionGroupIdentifier。 | - |
startDate | 交易开始日期,以 UNIX 时间表示的时间跨度的开始日期,以毫秒为单位。 | - |
endDate | 交易截止日期,以 UNIX 时间表示的时间跨度的截止日期,以毫秒为单位。 | - |
inAppOwnershipType | 按应用程序内所有权类型限制交易历史记录。 | PURCHASED,FAMILY_SHARED。 |
excludeRevoked | 交易历史记录是否排除退款和撤销的交易。默认值为false。 | true, false |
sort | 交易历史记录的可选排序顺序。响应按最近修改的日期对交易记录进行排序。默认值为 ASCENDING(升序),因此您首先会收到最旧的交易记录。 | ASCENDING, DESCENDING |
revision | 获取下一组最多20笔交易的令牌。所有回复都包含一个revision令牌。注意:对于使用revision令牌的请求,请包含与初始请求相同的查询参数。使用上一个History中的revision令牌。除初始请求外,所有请求都需要revision。 | - |
查询示例:
productId
、productType
和 subscriptionGroupIdentifier
查询参数可以同时指定多个值。例如,要按 NON_CONSUMABLE(非消耗型) 和 AUTO_RENEWABLE(自动续期产品类型)字符来筛选交易历史记录,请求中包含以下内容:
1 | GET https://api.storekit.itunes.apple.com/inApps/v1/history/{originalTransactionId}?productType=NON_CONSUMABLE&productType=AUTO_RENEWABLE |
其实更优雅的方式可能是 App Store Connect API 的形式:&filter[appStoreVersions.appStoreState]=READY_FOR_SALE,PREORDER_READY_FOR_SALE,READY_FOR_REVIEW
。
最后,交易历史记录接口返回结果只支持以下情况:
特别注意:消耗型应用内购买项目如果调用了 finishTransaction(_:),则不会在出现在舞台的交易历史列表中,所以,消耗型应用内购买项目不能使用这个接口作为校验接口!!!
测试 App Store 服务器通知
Request a Test Notification 让 App Store 服务器通知向开发者服务器发送测试通知。
1 | POST https://api.storekit.itunes.apple.com/inApps/v1/notifications/test |
接口响应的 testNotificationToken
字段是 App Store 服务器通知发送到开发者服务器的通知测试的测试通知令牌,每次请求获取的唯一标识 Token,这个 Token 用于下面的接口参数。
获取 App Store 服务器通知的测试结果
Get Test Notification Status,获取发送到开发者服务器的 App Store 服务器测试通知的检查状态。
1 | GET https://api.storekit.itunes.apple.com/inApps/v1/notifications/test/{testNotificationToken} |
根据 Request a Test Notification 接口获取到的 testNotificationToken
请求测试结果:
返回的响应有两个参数:
firstSendAttemptResult
:表示 App Store 服务器尝试向开发者服务器发送 TEST 通知的结果,如果不是 SUCCESS
,则如上图会返回原因,如果 TIMED_OUT
表示超时,SSL_ISSUE
表示开发者服务器的 SSL 证书有问题。根据这个字段就能测试和检查 App Store 服务器和开发者服务器之前的连通性。signedPayload
:JWS 格式的签名有效负载,包含 App Store 服务器发送到您的服务器的 TEST 通知。具体的 signedPayload
解码后的格式内容如下示例:
获取 App Store 服务器通知的历史通知
Get Notification History,获取 App Store 服务器尝试发送到开发者服务器的通知列表。
1 | POST https://api.storekit.itunes.apple.com/inApps/v1/notifications/history |
此接口的目的是,因为 App Store 服务器通知是苹果推送的通知,开发者是被动接收,总会因为各种情况(服务器宕机,运营商链路或云服务提供商故障等)导致无法按时接收到 App Store 服务器通知。所以,可以通过这个接口查询 App Store 服务器通知的历史记录:
查询接口的示例:
接口每次最多返回20条通知历史记录,所以响应会返回一个 paginationToken
字段,用来查询更多分页的通知结果。paginationToken 获取下一组最多 20 条通知历史记录,所有有更多历史记录的响应都包含 paginationToken 字段。
除了 StoreKit 2 增加了 environment
、recentSubscriptionStartDate
字段,App Store Server API 的 JWS 格式的签名交易也包含。
JWS transaction info Decoded Payload:
JWS renewal info Decoded Payload:
详细说明可以查看官方文档:environment 和 recentSubscriptionStartDate,这里不在复述。
同理 App Store Server Notifications 也有新增相应的 environment 和 recentSubscriptionStartDate 字段。
从这个图片可以看出,App Store Server API 是 App Store 服务器和开发者服务器之前,相互可以响应的流程。而 App Store Server Notifications V1 和 V2 通知,是 App Store 服务器主动通知开发者服务器,开发者服务器不能主动请求,所以导致了一些场景的缺陷。
服务器宕机是很常见的问题,但是宕机后,开发者就无法接收 App Store 服务器的通知。
所以,App Store Server Notifications V2 通知在首次尝试通知后没有收到来自开发者服务器的响应时会进行重试:
重试成功后,开发者服务器接收到的通知,可以并不再是顺序显示:
所以,开发者需要通过 signedDate
字段,确保通知的顺序逻辑正确,也就是说通知的结果状态以最新的 signedDate 时间来准,来更新用户能享受的服务。而重试的通知可能会出现重复的通知响应,所以开发者可以通过 notificationUUID
字段去重通知。
用户需要不断从订阅中获得价值,才会持续地订阅您的 App。定期更新您的 App,提供新内容和增强功能,以鼓励订阅者继续订阅。
App Store Server Notifications V2 提供了更多的通知类型,达到 28 个,未来还会增加更多。
这里一个用户订阅过程的可能会发生的通知:
从这个图中,开发者可以思考到什么?
Subscription loyalty(订阅忠诚度)
从苹果的 自动续期订阅 文档可以获取这样的思考:
通过使用 获取所有订阅状态 接口和 获取交易历史记录 接口,可确定用户的订阅状态并查看交易历史记录,帮助您识别并执行以下操作:
为避免由于账单问题而导致服务中断,请在 App Store Connect 中启用账单宽限期。Apple 将尝试解决账单问题,并在订阅者保留订阅访问权限的同时恢复订阅。如果订阅在这个期限内恢复,则付费服务天数的计数和您的收入都不会中断。如果用户在 60 天后重新订阅,则付费服务的天数将重置,您将收到一年的标准订阅费用,直到付费服务满一年为止。
简单来说,通过订阅通知,分析用户的忠诚度,根据用户不同的行为习惯和选择决定(通知),然后分析用户行为的背后原因,从而优化开发者的服务,从而提升订阅的忠诚度!
App Store 相关的调整不多,都是细节优化。
开发人员将能够更轻松地创建沙盒用户,并测试沙盒购买。相比以前少了 安全提示问题
、安全提示问题答案
、出生日期
三个选项。
增加了 Allow Purchase & Renewals
开关,用于测试订阅到期自动扣费和失败重试。
Xcode StoreKit 测试中添加了更多测试用例,例如退款请求、优惠代码兑换、订阅涨价、账单扣款重试等。这是一个不错的改进,但目前测试内购功能的开发者还不多,详细参考 What’s new in StoreKit testing - WWDC22。
App Store Connect API 增加了查询沙盒账号、清除沙盒内购历史记录、设置中断内购状态等,也增加内购、用户商店评论内容和回复、App 挂起诊断数据等接口。
最重要是,增加了内购项目的创建!
内购品项和订阅品项的相关 API:
目前截止本文发表,苹果 App Store Connect API 文档,依然还没有看到这些接口的描述!
最后,是苹果弃用 XML 流文档的形式与 App Store Connect 的交互,未来开发者,都需要迁移到 App Store Connect API!
这个怎么理解?参考我们之前开源的一款苹果 macOS 工具:《AppleParty(苹果派)》,它使用到了苹果 Transporter 命令工具,批量上传内购商品列表和上传 IAP 包文件等。预测 Reporter 和 altool 等命令也会被弃用。
苹果表示,今年秋天开始停用 XML 提交,强制推荐使用 App Store Connect API 接口。但目前还没有看到官网相关的说明文档!
今年 App Store 相关更新,可能最引人关注的功能,就是这个 Benchmarks in App Analytics
(App 分析中的基准)功能,,基准通过将与获客率、使用和盈利情况相关的绩效指标置于具体情境中,在整个客户旅程期间提供有价值的见解,这样您就可以很容易地看到您与同行相比的表现,并做出相应决策以实现业务目标。
查看自己 app 与同行相比的表现,并做出实现业务目标的决策。使用差异隐私技术,以确保机密信息的安全和私密性。苹果表示这个功能明年 2023 年初才上线,目前官方文档也没有找到详细的介绍。差异隐私技术介绍可以参考我们之前的文章《WWDC22 - Apple 隐私技术探索》。
关于 app 数据,Xcode 提供了功率、性能指标和诊断等新接口。
详细功能可以参考:Identify trends with the Power and Performance API - WWDC20 和 Track down hangs with Xcode and on-device detection - WWDC22。
在 App Store Connect app 中可以送审内购、新版本、In-App Event、产品面优化、自定义产品而等。
目前苹果支持送审的内容:
可以看到 iOS 除了新版本 app 送审,现在支持 In-App Event、自定义产品、产品面优化测试等。而 tvOS 和 macOS 目前还没有,可能明年 WWDC23 应该就支持一波了吧!
另外,需要提示一下,送审新版本 app 、In-App Event、自定义产品、产品面优化测试等,苹果是建议开发者可以合并提交一起送审,因为这样苹果会以当前送审的内容一起审核,提高苹果的审核效率?总之,提审这些项目后,如果有项目审核不通过,可以单独发布审核通过的内容。
关于 App Store 的优化,2022 年 1 月 20 日 推出适用于订阅的自定优惠代码,开发者可以自定义,如 VIP888
的优惠代码,用于推广活动,自定代码可通过直接 URL 或在您的 app 中兑换。2022 年 4 月 29 日 阐明 App Store 改善流程的标准和新的限期延长,苹果明确了 App 长期不更新被下架的细则,当一款 App 在过去三年内从未更新且未达到最低下载量 (即该 App 在连续 12 个月内完全没有或只有极低的下载量) 时,其开发者将会收到电子邮件,告知该 App 已被识别并可能从 App Store 中被移除,开发者收到通知起,有 90 天的时间来更新他们的 App。
关于 In App Purchase 和 App Store,随着这几年苹果的开放,已经很大程度上解决了开发者大多数的问题,从退款查询到所有订单查询,从被动通知到主动获取通知,从内购税率降低到提高 App 曝光量,苹果已经提供了非常多的接口、案例展示和建议。比如,自动续期订阅类型,目前已经复杂到不能再复杂,订阅群组、免费试用期限、推介促销优惠、促销优惠、优惠代码、计费重试、重新激活、续期等。
最后,大家觉得 In App Purchase
和 App Store
还有什么疑惑或痛点吗?
欢迎大家评论区一起讨论交流~
欢迎关注我们,了解更多 iOS 和 Apple 的动态~
]]>注:如若转载,请注明来源。
本文首发于 WWDC22 - Apple 隐私技术探索 - 掘金,欢迎关注我们 @37手游iOS技术运营团队 。
作者:iHTCboy
一直以来,苹果对隐私保护都非常严格,虽然每年新 iPhone 发布前已经被暴光的,但从 2018 年 Facebook 隐私门开始,不管国内还是海外,行业巨头还是个人用户,大家对于隐私的关注都达到了新的高度。正如乔布斯说,开放和安全是截然相反的事情,但这件不容易的事,总需要有人做。从 WWDC20 开始,对用户隐私的保护,又达到了史前的疯狂程度,如推出 ATT(App Tracking Transparency),成为广告行业的敌人,更不要说平时对权限的严控,所以,本文带大家一起回顾苹果关于隐私的升级变化。
“We’re trying to do two diametrically opposed things at once: provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks, etc. This is no easy task.”
“我们试图同时做两件截然相反的事情:为开发人员提供一个先进和开放的平台,同时保护 iPhone 用户免受病毒、恶意软件、隐私攻击等。这不是一件容易的事。”
Steve Jobs, October 17, 2007
一直以来,苹果对隐私保护都非常严格,虽然每年新 iPhone 发布前已经被暴光的,但从 2018 年 Facebook 隐私门开始,不管国内还是海外,行业巨头还是个人用户,大家对于隐私的关注都达到了新的高度。正如乔布斯说,开放和安全是截然相反的事情,但这件不容易的事,总需要有人做。从 WWDC20 开始,对用户隐私的保护,又达到了史前的疯狂程度,如推出 ATT(App Tracking Transparency),成为广告行业的敌人,更不要说平时对权限的严控,所以,本文带大家一起回顾苹果关于隐私的升级变化。
以往,开发者只是想从用户相册选择一张图片,但是只能允许 App 访问整个相册的权限或者不允许访问,这一刀切的做法一直被吐槽。苹果在 WWDC20 针对相册权限新增了 Limited Photo Library Access
模式,用户可以选择 App 访问全部或部分的照片:
同时,也推出了 PHPickerController 图片选择器:
相比已经淘汰的 UIImagePickerController 只能选择一张照片,PHPickerController 除了只支持 iOS 14+ 的缺点,它可以设置无上限张图片,另外也可以过滤选择的相册类型,图片、视频、livephoto 等。PHPickerController 是使用的系统独立进程,所以不需要申请相册权限,可以直接调用 API 访问,这也许是开发者应该考虑的一个更优雅的使用方式。
今年 What’s new in the Photos picker - WWDC22 苹果带来了更强大的相册过滤和已经支持 iOS/iPadOS/macOS/watchOS 全平台,也支持 SwiftUI 等。详细也可以查阅苹果文档 Selecting Photos and Videos in iOS。
也许你也有过这样的经历:在某团购 app 购买过商品,然而你浏览其他 app 时,广告一直在向你推荐同样的商品。
因为你可能使用同一个邮箱账号登陆了不同的 app,他们之间通过共享这些信息,从而定位到你:
在浏览器中,广告商 cookie、根据浏览器配置以及安装的字体和插件、网络 IP 等特征,生成设备的 指纹信息
来确定用户。
而在移动端 app 中,苹果提供 IDFA(Identifier For Advertisers,广告标识符) 来确实用户。为了保护用户隐私,早在 2012 年苹果公司就不再允许其生态的 App 获取用户的唯一标识符,但是商家在移动端打广告的时候又希望能监控到每一次广告投放的效果,因此,苹果想出了折中的办法,就是提供另外一套和硬件无关的标识符,用于给商家监测广告效果,同时用户可以在设置里改变这串字符,导致商家没有办法长期跟踪用户行为。
设置 IDFA 路径在 iOS 14 以下 设置->隐私->广告->还原广告标识符
,而在 iOS 14 苹果在 WWDC20 推出 ATT
(App Tracking Transparency
, 应用追踪透明度)框架,旨在最终全面关闭 IDFA. 如果简单来说,苹果把 IDFA 是否允许 app 获取的权限交给了用户来选择:
当然,跟踪用户设备的目的是什么?最原始的目的是 广告归因
。他们希望将购买归因于广告点击,以便商家知道将广告预算集中在哪里,此类归因用于衡量哪些广告有效。但随着移动端成为全球用户必备的随身设备,单单的广告归因已经不能满足他们的目的,收集购买习惯以及其他隐私信息,它们变得比你自己更了解自身的购买需求!
苹果推出的 SKAdNetwork
就是希望在广告端袜掉用户的标识,各 app 之间的用户标识,要不要共享给第三方使用,应该由用户自己决定:
SKAdNetwork 归因数据本身不具有任何用户标识符,所以无法跟踪用户。SKAdNetwork 是让广告平台在不获取 IDFA 的前提下,对用户的点击和安装行为提供的一套追踪解决方案。由于 Apple 的介入,将直接横跨设备与 App Store,并且不会把任何设备信息透露给广告主,并且更有利于防作弊。
当用户点击广告时,一个带有签名信息的 App Store 产品界面呈现出来,签名信息标记了此次广告活动。如果用户安装并且打开了 app,设备发送一个安装验证通知给广告网络。这个由 Apple 签名的通知包括广告活动 ID,但是不含用户或设备相关的数据。通知还可以包含一个转化数值和来源应用 ID,这个取决于苹果设定的一个隐私阈值。
SKAdNetwork 最大的问题就是提供了聚合的数据,但对于广告来说,这个过程已经不是简单的跟踪用户,而跟踪广告也是非常的重要,因为一个广告可能有多个不同的素材和不同的渠道测试等。首先 SKAdNetwork 回调通知可以获取的 数据:
SKAdNetwork 2.0
1 | { |
SKAdNetwork 3.0
1 | { |
字段说明:
注:
今年 WWDC22,苹果带来了 SKAdNetwork 4.0,为广告商提供有关其广告系列的更多信息,同时继续保护用户隐私。
分层源标识符
这个字段以前称为 campaign-id
(活动ID字段),允许广告商识别安装归因于哪个广告系列,以及额外的归因信息,并且以前只能有 0~99 的 campaign ID。广告商可以根据自己的目标配置这个四位数值,例如广告系列价值、广告投放或广告创意类型。
虽然苹果提供了 4 位数字配置,但是并不一定返回 4 位。苹果始终至少包含两位数字,根据广告系列所满足的安装次数和用户隐私级别,最多可以包含四位数字。例如,如果广告系列没有生成足够数量的安装,则回发的源标识符字段中只会显示两位数字。这为广告商提供了更大的广告系列灵活性,并在达到隐私阈值时提供了额外的归因洞察力,同时保护了跨应用程序的用户隐私。
为什么苹果说足够数量的安装才会返回更多的位数?这里有一个概念 differential privacy techniques
(差分隐私技术),利用这种技术,避免可以跟踪定位到用户层级的数据。下文会提到,这里暂时先略过,有兴趣可以翻到下文查看。
多次转换通知
SKAdNetwork 最大的一个问题是,归因延迟至少 24 小时,严重影响了转换率的统计,投放的广告不能马上看到效果,这是广告投放最可怕的事,投了钱不能马上看到效果,是亏还是赚还要等。虽然今年苹果并没有提高实时回调(估计未来也不会),但提供了最多三次通知,每次都基于特定的转换窗口(分别为0-2天、3-7天和8-35天)。这使他们能够更好地了解从广告系列中安装应用程序的人随着时间的推移与广告应用程序的互动程度。
注:每个转换窗口可以包含多个活动广告。SourceID、SourceAppID和粗粒度转换值是有条件的,只有在达到隐私阈值时才包含在第二次和第三次回调中。
需要说明的是,使用 SKAdNetwork 不需要用户允许 App Tracking Transparency 广告跟踪,因为 SKAdNetwork 是聚合数据,从回调的数据中,广告商是不能反向定位用户信息,所以并不需要 ATT 的授权。
同理,因为没有用户层级的数据,LTV(Life-Time Value)的数据将会失效。这对广告主来说,是巨大对的影响。以往跟踪 LTV 数据然后进行媒体侧投放买量的行为,将会失效。所以广告主一直想跟踪用户,除了 ATT 外,设备指纹是目前剩下的方式,但根据 Apple Developer Program 许可协议,开发者不得为了唯一识别设备而从设备中获取数据。用户或设备数据的示例包括但不限于:用户的网页浏览器及其配置、用户的设备及其配置、用户的位置或用户的网络连接。引用SDK的应用程序,包括但不限于广告网络、归因服务和分析,如果发现参与这种做法,可能会被App Store拒绝。
Safari 浏览器拥有多项先进功能,帮助保护你的隐私安全,防止你受到跨网站跟踪,并能最大限度减少传送给第三方的数据。对于苹果来说,没有浏览器广告业务,隐私保护自然做的更加好。
PCM(Private Click Measurement,私人点击测量)隐私保护广告点击归因,是苹果提出的一个 Web 网络标准技术,浏览器充当了搜索网站和商家网站的中间人。 中间人会限制网站之前发送的信息,过滤掉用户敏感信息,只发送归因的参数,比如 Campaign(广告组) 和 Convert (转化事件)。
详细技术可以阅读苹果官方文档:
SKAdNetwork 4.0 支持网页版 SKAdNetwork,让广告商能归因那些会转至推广 App 的 App Store 产品页面的网页广告,除了移动网站外,苹果还支持 iOS 和 iPadOS app 的 SFSafariViewController。
App Store 让开发者能在 175 个地区提供面向 iPhone、iPad、Mac、Apple TV 及 Apple Watch 的 App 和服务。如何触及更多用户,并不断发展您的业务,App Store 提供了巨大的商机,自定产品页、产品页优化、App 内活动、优惠订阅等等。
衡量 App 表现
有多少用户在 App Store 上搜索或浏览时发现了您的 App?哪些 App 和网站吸引了用户查看您的产品页?怎么衡量自己 App 的下载次数(包括首次下载次数、重新下载次数和总下载次数)以及您的 App Store 转化率?
苹果今年 WWDC22 提供 App 分析中的基准 功能,基准通过将与获客率、使用和盈利情况相关的绩效指标置于具体情境中,在整个客户旅程期间提供有价值的见解,这样您就可以很容易地看到您与同行相比的表现,并做出相应决策以实现业务目标。
举例来说,查看 app 转化率,开发者可以了解自己 app 与同类 app 的表现情况:
App Store 通过独家提供的宝贵数据,来深入了解和发现您的 App 的表现效果。苹果提供转化率、1/7/28天留存率、崩溃率和平均付款率等。
开发者可能会有疑问,苹果这是公开开发者的数据吗?苹果表示对照组 app 使用 differential privacy techniques
(差分隐私技术),以确保机密信息的安全性和私密性。那么什么是差分隐私技术?
举例来说,假设有一个问题用户可以回答 Yes 或 No,那么如果用户选择 Yes
,那么这个选择上传到服务器时,会先随机生成 Yes 或者 No,那么有 50% 概率是 Yes 也就是用户的选择。如果是 No,在随机生成一次 Yes 或者 No,然后有 25% 概率是 假数据
。因为数据有可能是假信息,所以可以避免通过用户的数据推导(定位)到指定的用户。所以差分隐私技术能够增强数据匿名和数据汇总的隐私保护程度。
这里读者可以有疑问,这样数据样本就不具有准确性了吗?所以,差分隐私技术的一个前提条件,是数据量必然很大,才能减少这些随机数据的影响。从上面的例子来说,至少 75% 是正确的选择,最高接近 100% 是正确选择。
关于差分隐私技术,可以参考苹果文档了解更多:
iOS 16 和 watchOS 9 中引入的开发者模式,用于保护用户在设备上无意中安装有害软件的问题,并减少仅由开发者功能暴露的攻击载体。
对于开发者来说,此举可能比较麻烦,从体验来说打开开发者模式还算快。对于用户来说,影响是比较深远,像我们之前的文章提到 iOS15 安全漏洞分析:价值10万美元的漏洞曝光,0 day 漏洞还是 1 day 漏洞,对于不升级系统的用户,破坏性依然存在,但如果有了开发者模式,普通用户受影响的范围会降低很多。
对于使用签名分发包体的方式,未来估计不复存在,一方面教育用户启动开发者模式成本很高,另一方面苹果对于开启做了多重警告提示用户。另一种企业证书,目前苹果已经不在审批新的企业证书,所以未来只会越来越少,直到消失。至此,安全性的价值远大于开发者启动开发者模式带来的不便。
详细可以参考苹果文档:Enabling Developer Mode on a device。
除了隐私权限由用户来决定,苹果也将越来越多的隐私权限使用的可见性。例如 WWDC20 推出的 隐私标签
、App 隐私报告
:
App Store 里的产品介绍页面包含一个隐私处理说明版块,以简洁易读的标签摘要形式,呈现由开发者提供的隐私信息处理方式报告,确保用户能在充分知情的情况下进行选择。
开启“记录 App 活动”功能后,你所有 app 的行为都一目了然。“设置”中的这个版块让你可以查看过去 7 天内各 app 访问你的位置、照片、摄像头、麦克风以及通讯录的频率。它还会显示这些 app 访问其他域的频率。结合隐私标签所提供的信息,你可以更加全面地了解所用 app 如何处理你的隐私。
在 iOS 16,可以通过菜单栏点击查看当前有那些 app 在使用定位权限。摄像头、麦克风等也能点击查看是那个 app 在使用对应的权限了。
粘贴板使用透明度
在 iOS 15 中,当有 app 从粘贴板拷贝内容时,系统会发出通知,提醒用户留意此行为。而 iOS 16 开发者粘贴来自其他 app 的内容时,需要弹窗请求用户允许,且在未经允许前,无法访问粘贴板的内容。
有三种方法可以避免此提示出现在 app 中:
UIDevice.name
Entitlements 文件中包括 com.apple.developer.device-information.user-assigned-device-name
,才能获取到真实的设备名。但目前从苹果文档 UIDevice 还没有看到相关的配置说明。
macOS app 权限
macOS Ventura 系统配置 UI 更新,并且对 App 权限进行更加精细的管理,包含 app 要调用或删除其它 app(与当前 app 包名不一样的 app),或者电脑启动时,自动启动的 app 或者服务等,都有严格的控制:
另外,苹果提供 SMAppService API 来控制这些服务能力。
Gatekeeper(门禁)
Gatekeeper(门禁)技术,旨在确保只有受信任的软件才能在 Mac 上运行。
Gatekeeper 检查新下载的应用程序的完整性,在 macOS Ventura 中,Gatekeeper 将检查所有经过公证的应用程序的完整性,而不仅仅是隔离的应用程序。有一些 app 往往不止是一个 app,而有多个不同的 app,如果需要更新这些 app,需要在 Info.plist 添加 NSUpdateSecurityPolicy
来指定那些 app 包更新权限。
1 | "NSUpdateSecurityPolicy" => { |
注:截止本文发表,苹果还没有更新
NSUpdateSecurityPolicy
相关详细的文档。
设备连接
大家会经常看到这样的授权,本地局域网或者蓝牙授权:
需要这些权限,是因为连接的管理设备选择需要了解所有设备,但这提供了对不必要信息的访问,并带来设备指纹风险。
iOS 16 可以通过 DeviceDiscoveryExtension
Framework 来引导用户连接对应的设备。但截止目前还没有找到相关的文档说明。
Apple、谷歌与微软承诺拓展对 FIDO 标准的支持,以加速普及免密码登录
来源
隐私与安全,最安全的身份验证可以是根据用户的生物特征来验证,而利益于指纹识别、面部识别等技术成熟,Passkeys 就是基于这些基础而免于输入密码。而验证码是用于验证用户和机器人的区别,在我们生活中,验证码已经无处不在,而苹果基于自家的 iCloud、Apple ID 账号体系提供了 Private Access Tokens
(PAT,私有访问凭据)来信任设备。
详细技术细节,可以观看 Meet passkeys - WWDC22、Replace CAPTCHAs with Private Access Tokens - WWDC22,或阅读 遇见 Passkey、验证码的替代者—私有访问凭证 文章。
2022 年 7 月 6 日,苹果更新了 iOS 16 beta2 版本开始,增加了 Lockdown Mode
(锁定模式)
Lockdown 旨在为极少数用户提供可选的极端保护。这些用户因其身份或工作性质,可能被极为先进的数字威胁锁定为攻击目标,如来自 NSO Group 等在国家授意下开发间谍软件的私人企业发起的攻击。在 iOS 16、iPadOS 16 和 macOS Ventura 中开启 Lockdown 模式将进一步加强设备防护,严格限制部分功能,大幅减少受攻击面,以免给具高度针对性的间谍软件可乘之机。
Lockdown 模式发布时将包括下列保护功能:
“我相信人都是聪明的,有些人也愿意分享更多数据。 这就要征询他们的同意,每一次都征询。就算他们厌倦了,也得让他们来告诉你不必再问了。而且你要确切地告诉他们,你会怎样使用他们的数据。”
Steve Jobs
2010 年,万物数字化大会 (All Things Digital Conference)
正如乔布斯所说,隐私保护,最终让用户决定。但需要注意,在安全的环境下让用户全权决定,但不是代表一味地追求完全自主。苹果通过技术在 先进和开放
、隐私和安全
之间,找到了关联。
区块链 Web 3.0 概念虽然火热,但其不可篡改也不可撤销也未必适合所有场景。2022 年 6 月 30 号,苹果强制要求具备账号体系的 App 必须提供 帐户删除 的功能,对于用户来说,删除数据重要吗。
ATT 对于广告行业,使用 SKAdNetwork,就像投放广告,没有最好的广告,也没有最好的唯一方式,在垄断与隐私方面,依然需要探索更多的可能性和平衡性。
欢迎关注我们,了解更多 iOS 和 Apple 的动态~
]]>注:如若转载,请注明来源。
本文是《WWDC22 内参》参与创作者,首发于 【WWDC22 10039】Xcode StoreKit 测试的新功能 - 小专栏。
基于 Session 10039 梳理
作者:iHTCboy,目前就职于三七互娱37手游,从事游戏 SDK 开发多年,对 IAP 和 SDK 架构设计有丰富的实践经验。
审核:
黄骋志(橙汁),老司机技术社区核心成员,现于西瓜视频负责稳定性 OOM/Watchdog 相关工作。SeaHub,目前任职于腾讯 TEG 计费平台部,负责搭建服务于腾讯系业务的支付组件 SDK,对 IAP 相关内容及 SDK 设计开发有一定的经验。
王浙剑(Damonwong),老司机技术社区负责人、WWDC22 内参主理人,目前就职于阿里巴巴。
在 Xcode 12 之前,App 内购买项目是不能在 Xcode 模拟器中进行购买,只能使用真机进行测试内购充值,因为模拟器无法连接到 App Store 服务器进行交易。苹果在 WWDC20 推出了 StoreKit Testing,通过 Xcode 12 创建 StoreKit 配置文件和搭建本地测试环境,实现本地 App 内购买和验证收据等测试流程,而无需依赖 App Store 服务器。而今年的 WDC22 苹果对 StoreKit 测试流程改进完善,包含 Xcode 14 中测试功能的优化,支持订阅商品更多场景的测试,还有 StoreKit 配置文件通过 App Store Connect 自动同步等等。
在讲解 StoreKit 测试的新功能之前,小编先带大家回顾一下 StoreKit 测试的历史流程,这样我们才能理解这个新功能的改进的意义。在苹果文档 Original API for In-App Purchase 中有这样的一张图:
从这张图可以看出 StoreKit API 的测试必须依赖四方:
这样互相循环依赖的关系,导致开发者需要测试 StoreKit 功能就非常的被动,主要的问题是依赖 App Store 服务器,一方面是 StoreKit 内购买需要通过 App Store 服务器创建交易(transaction),另一方面是开发者需要通过 App Store 服务器来校验票据(receipt)。而在 Xcode 和模拟器中,StoreKit 并不支持 App Store 服务器交互,导致无法完成流程的闭环。
所以,要测试 App 内购买功能有以下三种测试环境:
Production
:生产环境,也就是 App Store 下载的 app,需要使用真钱才能进行测试。Sandbox
:沙盒环境,开发者用 Development 或 Ad Hoc 证书打包调试时, 在真机中可以进行 App 内购买测试,但需要登录沙盒测试账号。TestFlight
:测试环境,面向外部测试员,App 内购买项目使用的是沙盒环境,但不需要测试员登录沙盒测试账号。苹果在 WWDC20 推出了 StoreKit Testing,它的目的是脱离 App Store 服务器,让开发者本地就能完成 App 内购买流程。原理是,Xcode 中创建一个 StoreKit Configuration File
本地配置文件,Xcode 通过这个配置文件模拟 StoreKit 与 App Store 服务器的交互流程,从而实现在 Xcode 模拟器中发起 App 内购买操作。
具体的操作是在 Xcode 项目中新建文件,选择创建 StoreKit Configuration File
,然后选中生成 .storekit
后缀的文件,点击左下角的 +
可以选择创建商品类型,根据需要填写要测试的商品信息。
要启动 StoreKit Testing 功能,需要在项目的 Edit Scheme
中切换到 Run
栏中的 Options
标签,再在 StoreKit Configuration
中选中需要测试的 StoreKit 配置文件即可。然后运行项目后,在 Xcode 的调试栏中点击 Manage StoreKit Transactions
图标,可以打开订单交易管理界面,可以对交易的任一订单进行删除、退款、中断、同意或拒绝购买等操作。
Xcode 本地创建和生成的交易订单的票据是使用单独的 RSA 密钥生成,使用 PKCS7
填充算法,公钥可以在 Xcode 的 Editor
菜单栏中 Save Public Certificate
导出。
另外,苹果推出了 StoreKitTest Framework 用于在 Xcode 中编写单元测试和持续集成测试,以实现 StoreKit 自动化测试。简单的一个测试用例如下:
1 | import XCTest |
最后,关于 WWDC20 StoreKit Testing 的详细介绍,可以参考我们之前的文章 WWDC20 - 介绍 Xcode 中的 StoreKit 测试。
目前 Xcode 中 StoreKit 测试新流程如下图:
开发者可以串联 Xcode、App Store Connect、TestFlight、App Store 实现完整的流程,StoreKit 在沙盒和 Xcode 中的测试。
我们上面讲到的 StoreKit Configuration 文件的创建和配置,其实是比较麻烦的,因为开发者在 App Store Connect 创建 App 之后需要创建配置 App 内购买商品,然后在 Xcode 中创建 StoreKit Configuration 文件后,还需要把全部的商品信息再配置一次,对于开发者来说是非常麻烦的重复事情。
在 Xcode 14 中,苹果解决了 StoreKit Configuration 文件需要手动配置的商品的问题,开发者在创建时 StoreKit Configuration 文件时,可以选择勾选 Sync this file with an app in App Store Connect
,然后选择开发者团队和 App ,就可以从 AppStore Connect 拉取已经填好参数的配置文件,同时配置文件也可以进行更新,具体看下文介绍。
这里选择的 App 主要目的是确认同步那个 App 的商品信息,不需要与当前项目的 App(Bundle ID)一致,也能同步商品信息下来。
App Store Connect 同步的 StoreKit Configuration 文件,只能点击刷新按钮同步最新的商品更新信息,而不能在 Xcode 中修改。如果需要本地修改,可以选择配置文件后,点击 Xcode 的 Editor
菜单栏中 Convert to Local StoreKit Configuration
转换成本地配置文件,转换成功后将不能在从 App Store Connect 中同步了。
如果转换成本地配置文件,Xcode 会有一个警告提醒,点击 Conver File
才能转换成功。另外,如果不想转换,可以点击某个商品的配置,然后复制粘贴到其它的本地配置文件中,这里就不在赘述。
同步文件的区别
其实 StoreKit Configuration 是一个 json
格式的配置文件。
未勾选同步时,创建的 StoreKit 配置文件内容:
1 | { |
创建同步的 StoreKit 配置文件(未点击同步前)的内容:
1 | { |
从内容上可以猜到,
identifier
表示配置文件的唯一标识,_applicationInternalID
表示app id
,而_developerTeamID
表示开发者的团队唯一标识。
苹果是用 settings
字段里的 _applicationInternalID
和 _developerTeamID
这两个键值共同来判断是本地的还是同步的配置文件:
1 | "settings" : { |
直接修改本地的配置文件,可以实现同步 AppStore Connect 的配置。但是需要注意,本地配置的商品信息会被删除,覆盖来 AppStore Connect 配置的商品信息。
一个同步后的 StoreKit 配置文件的内容示例:
1 | { |
同步的 StoreKit 配置文件与不同步的 StoreKit 配置文件的商品内容格式是一样的,这里就不在赘述。
之前的 Xcode 订单交易管理界面,可以对交易的任一订单进行删除、退款、中断、同意或拒绝购买等操作。
Xcode 14 中,点击某个交易订单,可以看到右侧栏会显示商品的交易详细信息,如果是订阅商品还包含订阅过期时间、续订时间等等。另外底部新增搜索栏,可以搜索商品的 ID 或交易时间等。
那么如何结合 Xcode 进行 StoreKit 测试,如果之前大家没有尝试过,看看这几个案例就能大概学会啦。
在 iOS 15 苹果提供了 app 里申请退款的接口:
在 SwiftUI 中使用 refundRequestSheet(for:isPresented:onDismiss:) 接口实现退款的示例:
1 | struct RefundView: View { |
而在本地订单交易管理器,也可以点击 Refund Purchases
图标进行退款。
那么退款成功后,开发者需要处理退款后的 app 的业务逻辑测试,在 StoreKit 2 中,使用 Transaction.updates
监听所有交易的更新,更新交易的 revocationReason 字段是一个结构体,其中 .developerIssue
和 .other
与上上图中可选择的退款原因是相对应的,所以开发者很容易对这两个撤销原因进行测试。
1 | for await update in Transaction.updates { |
最后,退款测试的环境要求如下:
Xcode | Sandbox | |
---|---|---|
iOS and iPadOS | 15.2 | 15.0 |
macOS | 12.1 | 12.0 |
关于 Offer codes
(优惠代码)我们这里就略过了,读者可以查看苹果文档了解 优惠代码。
优惠代码测试的测试,首先是在 StoreKit 配置文件的订阅商品中点击添加 Offer Codes 栏的 +
进行配置:
在 iOS 14 中就增加 presentCodeRedemptionSheet() 接口,实现 app 内兑换优惠代码:
而在 SwiftUI 中需要 iOS 16+ 中通过 offerCodeRedemption(isPresented:onCompletion:) 接口实现 App 内兑换优惠代码的示例:
1 | struct SubscriptionPurchaseView: View { |
兑换优惠代码成功的交易,可以在本地订单交易管理器,交易订单的右侧栏 Renewals
标签中,看到订阅更新的信息。
那么开发者需要处理兑换优惠代码后的 app 的业务逻辑测试,在 StoreKit 2 中,使用 Transaction.updates
和 Product.SubscriptionInfo.Status.updates
监听所有订阅商品交易的状态更新:
1 | for await verificationResult in Transaction.updates { |
其中 Product.SubscriptionInfo.Status.updates
接口中返回的交易字段 offerType
可以确认订阅的优惠类型,关于 OfferType 优惠类型可以阅读文档:优惠类型。
1 | for await status in Product.SubscriptionInfo.Status.updates { |
优惠代码(Offer Codes)测试的 StoreKit 配置在 Xcode 13.3+ 以上就可以设置,所以搭配的测试的设备系统必须是 iOS 15.4 或 iPadOS 15.4 以上。
随着 App 订阅的流行,很多 App 的订阅可能因为业务或者服务器成本等原因,提高订阅价格。而部分订阅涨价需要用户同意才能续订,今年 WWDC22 苹果推出了 StoreKit Message 接口,开发者可以在 app 内显示涨价提示:
关于 StoreKit Message 接口介绍,可以参考 WWDC22 - 探索 In-App Purchase 新特性。StoreKit Message 接口代码示例:
1 | private var pendingMessages: [Message] = [] |
关于提高自动续期订阅价格可以参考文档:
那么,要怎么提高自动续期订阅价格,在本地订单交易管理器可以点击图标或者右键点击 Request Price Increase Consent
按钮,这样就表示这个商品要提高下一个订阅周期的订阅价格:
因为除了利用 StoreKit Message 提示弹窗中点击同意涨价外,用户也可能会通过电子邮件等其它方式对价格上涨做出选择,所以为了模拟这个场景,可以在本地订单交易管理器,点击 Approve
(批准)和 Decline
(拒绝)按钮来模拟用户的选择。
最后,可以通过 priceIncreaseStatus
判断用户是否同意涨价,通过 expirationReason
字段的 .didNotConsentToPriceIncrease
类型判断用户没有同意涨价。在 StoreKit 2 和 iOS 15 实现的代码示例:
1 | for await status in Product.SubscriptionInfo.Status.updates { |
使用 iOS 15.4 可以在 StoreKitTest Framework 中编写单元测试代码进行涨价测试:
1 | let session: SKTestSession = try SKTestSession(configurationFileNamed: "<#Configuration name#>") |
订阅涨价测试支持在 Xcode 13.3 以上使用:
Status | Message | |
---|---|---|
iOS and iPadOS | 15.4 | 有 |
macOS | 12.3 | 无 |
watchOS | 8.5 | 无 |
tvOS | 15.4 | 无 |
注:其中 StoreKit Message 功能只有 iOS 16 或 iPadOS 16 以上支持,其它系统暂不支持。
扣费重试一般是出现在玩家的银行卡信息过期或者绑定的支付方式过期或撤销等,导致订阅无法按时续期,系统会进行扣费重试。如果重试扣费成功,或者用户续费,则订阅续订成功:
默认情况下扣费重试阶段,用户的订阅服务已经过期,导致用户无法使用服务。为了解决扣费重试阶段,用户还能享受订阅服务,苹果提供了一个过渡阶段:Grace period
(宽限期),在宽限期内订阅服务可继续享受。
要实现扣费重试和宽限期的测试,可以在 Xcode 中分别选择 Enable Billing Retry on Renewal
和 Enable Billing Grace Period
:
注:为了加速订阅过期时间,可以在
Subscription Renewal Rate
选择更快的订阅过期时间,这样更快的进入模拟的测试阶段。
最后,要模拟解决扣费失败后成功的场景,可以在本地订单交易管理器中,点击 Resolve Issues
表示解决扣费问题,让扣费成功后进入到下一个订阅周期中。
在代码逻辑中处理,gracePeriodExpirationDate
字段的时间小于当前时间,就表示订阅在宽限期内,允许用户继续享受订阅服务。而 isInBillingRetry
字段,则表示扣费重试阶段。
1 | for await status in Product.SubscriptionInfo.Status.updates { |
在订阅扣费重试阶段,可以提示或引导用户解决扣费失败的问题。具体来说,可以引导用户打开链接 https://apps.apple.com/account/billing
会跳转到 App Store 用户账号的 管理付款方式
,从而解决问题。
1 | struct SubscriptionStatusView: View { |
使用 iOS 15.4 以上可以用 StoreKitTest Framework 中编写单元测试代码实现扣费重试测试:
1 | let session: SKTestSession = try SKTestSession(configurationFileNamed: "<#Configuration name#>") |
订阅扣费重试测试支持在 Xcode 13.3 以上使用:
Xcode 13.3 | Sandbox | |
---|---|---|
iOS and iPadOS | 15.4 | 16.0 |
macOS | 12.3 | 无 |
watchOS | 8.5 | 无 |
tvOS | 15.4 | 无 |
Server | N/A | 有 |
注:订阅扣费重试,Sandbox 环境下,苹果会发送 App Store Server Notifications 订阅状态变更的通知,如
DID_FAIL_TO_RENEW
/EXPIRED
/BILLING_RETRY
。而 Xcode 环境测试则不会有通知。
在 iOS 12 之前沙盒账号测试内购买需要先登出 App Store 账号,在 iOS 12 开始,苹果才提供了单独的沙盒测试账号入口:
开发人员可以更轻松地创建沙盒账号,相比以前少了 安全提示问题
、安全提示问题答案
、出生日期
三个选项。另外,密码强度不满足时会有提示语。
App Store Connect API 新支持:
简单来说,沙盒测试账号中增加了 Allow Purchase & Renewals
开关,用于测试订阅到期自动扣费和失败重试。
比如当关闭这个按钮时,表示自动续订失败,订阅状态会进入扣费重试和宽限期中,此时就可以在沙盒环境中测试。
如果是 App Store Server Notifications V2 会收到 DID_FAIL_TO_RENEW
GRACE_PREIOD
宽限期的通知:
开发者也可能通过 App Store Server API 主动查询订阅状态:
如果是 Original StoreKit API,则通过苹果票据验证接口获取状态:
关于 StoreKit 和 In-App Purchase 测试,一般开发者会更加关注在 Sandbox(沙盒环境)下测试 App 内购买功能,因为这与 Production(生产环境)的区别最小,但是测试流程比较麻烦,需要开发者证书、沙盒测试账号登录等,开发者账号还必须成功绑定银行卡信息后才能调试内购买功能。如果是订阅类型的商品,还需要覆盖测试的场景非常多,测试起来更加的麻烦。
从上文的案例和代码示例可以知道,StoreKit Testing 借助 SwiftUI 和 StoreKit 2,让测试流程的实现技术更加自然。一方面是 SwiftUI 可以快速构建 UI 界面,更容易实现商品页面的展示和调整;另一方面 StoreKit 2 的 JWS transaction 票据不需要通过苹果的 StoreKit 服务器验证,更方便实现票据的校验流程。所以,对于新项目,或者使用 StoreKit 2 改造内购买逻辑流程时,使用 StoreKit Testing 将会大大提高代码测试的效率。
所以基于 Xcode 的 StoreKit Testing 和 StoreKitTest Framework 框架,开发者有了更加高效的测试方式。而今年 WWDC22 改进后更加方便和高效,开发者无需关注证书配置和沙盒环境账号等,就能实现本地的内购买测试,对于需要验证某个商品购买逻辑完备性,或 App 新增加内购买功能时,只需要闭环本地的代码逻辑而无需验证票据等,StoreKit 本地测试会更加顺畅,建议读者可以尝试使用!
本文是《WWDC22 内参》参与创作者,首发于 【WWDC22 10040】 探索 In-App Purchase 集成和迁移 - 小专栏。
基于 Session 10040 梳理
作者:iHTCboy,目前就职于三七互娱37手游,从事游戏 SDK 开发多年,对 IAP 和 SDK 架构设计有丰富的实践经验。
审核:
黄骋志(橙汁),老司机技术社区核心成员,现于西瓜视频负责稳定性 OOM/Watchdog 相关工作。SeaHub,目前任职于腾讯 TEG 计费平台部,负责搭建服务于腾讯系业务的支付组件 SDK,对 IAP 相关内容及 SDK 设计开发有一定的经验。
王浙剑(Damonwong),老司机技术社区负责人、WWDC22 内参主理人,目前就职于阿里巴巴。
苹果去年 WWDC21 推出了 StoreKit 2、App Store Server API 和 App Store Server Notifications V2,今年 WWDC22 基于这些功能的基础上,增加了一些新的 API 和一些服务的优化。另外,苹果针对这些新特性的疑虑进行了解答,例如 JWT/JWS、兼容性、安全性、订阅通知、服务端集成和迁移等等,最后提供了最佳实践的建议。
本文内容分成两个主题,分别是 App Store Server API 和 App Store Server Notifications,并结合去年和今年推出的新特性,进行深入浅出的探索。如果读者对去年 WWDC21 相关的内容还不太熟悉的话,推荐先阅读我们去年的文章:
开始之前,为帮助读者理解本文将提及的名词,我们一起梳理和回顾关于 In-App Purchase 的名词:
名词 | 功能 | 说明 |
---|---|---|
IAP 或 In-App Purchase | App 内购买项目,在所有 Apple 平台上,可以利用 IAP 支付系统,直接在您的 App 内提供额外的内容和功能,包括数字商品、订阅和增值内容等。 | In-App Purchase 简写为 IAP 或者 内购 ,都是非苹果官方写法,但开发者普遍都接受,所以本文也将两者等同关系处理。 |
App Store Server API | WWDC21 推出的 REST API,它是一种强大、安全和高效的 Server to Server API,提供获取数据和执行操作的服务。 | 请求接口使用 JWT 验证,接口返回的信息使用 JSON Web Signature (JWS) 规范格式加密签名。 |
App Store Server Notifications V1 和 App Store Server Notifications V2 | 目前有 V1 和 V2 版本。通过来自 App Store 的服务器通知实时监控 IAP 事件。 | V1 版本是 WWDC17 推出用于自动续期订阅的订阅状态变化通知,WWDC20 增加了退款通知,API 返回的内容是 JSON 格式。V2 版本是 WWDC 21 推出,API 返回的内容是 JSON Web Signature(JWS)规范格式加密签名,移除和新增部分通知类型,一些通知类型增加子类型(SubState)。 |
Original API for In-App Purchase 或 Original StoreKit | IAP 支付系统,原始的 StoreKit API,用于区分 StoreKit 2。 | 获取的交易票据叫 App receipt ,需要通过 VerifyReceipt API 来解析票据内容。 |
StoreKit 2 | WWDC21 推出的全新的基于 Swift 的 API,仅在 iOS15+ 生效。使用 Swift 的并发特性简化接口,并且使用 JWS 格式的交易票据。 | 获取的交易票据叫 JWS transaction 或 Signed transaction ,开发者可独立进行验证,而无需通过苹果服务端 API 解码。另外需要注意,与 Original StoreKit 都是基于 StoreKit Framework 的 API,所以并不是叫 V2 版本。 |
originalTransactionId | IAP 交易成功时,App Store 生成的唯一交易标识符。此字段可通过 StoreKit API、App Store Server API 和 App Store Server Notifications 等方式获取。 | 自动续期订阅的项目使用此字段作为唯一标识,而续订成功的交易票据中 transactionId 会更新。另外部分的 App Store Server API 使用此字段作为请求参数。 |
首先,我们先来看看 App Store Server API 的变化,会从下面的四个方面进行阐述:
苹果去年 WWDC21 推出了 App Store Server API,这套接口兼容 Original StoreKit 和 StoreKit 2,开发者服务端可以直接使用,因为是新接口,所以无迁移或兼容的问题。 其中有 5 个 API 是通过 originalTransactionId
作为查询的参数,这个参数可以通过 receipts(票据)、signed transactions(签名的交易)、signed renewals(签名的续订信息)和 notifications(通知)等获取。
这几个接口解决了很多内购场景的问题,多年以来只能被动式接收苹果 IAP 流程的通知,导致开发者对 IAP 流程的处理总是不及时。比如自动续期订阅的续订,如果开发者接收苹果服务端通知异常,甚至用户不打开 App 的情况下,订阅到期后,用户是否有续订,开发者总是慢半拍,而现在通过 subscriptions API 开发者就可以实时用户查询订单状态,提升了订阅产品的用户体验。还有主动查询退款 refund lookup API,可以主动或定时检索用户的购买订单,及时发现恶意退款和异常购买,避免用户和开发者蒙受损失。
以上接口的详细介绍,可参考我们之前的文章:IAP 用户退款与客诉处理优化。
去年还有一个 lookup
API,这个接口根据用户提供的 orderId
来查询用户的每笔支付对应的开发者交易订单信息,从而让开发者更好地帮助用户解决问题。比如用户反馈充值成功但没有收到金币,这时候让用户提供苹果收据订单号 orderId
,开发者就能查到此订单号对应的 originalTransactionId
交易标识,这样就能根据用户订单号关联开发者订单号的问题,从而解决以前无法根据用户的收据截图判断是否真实的支付成功的问题。
另外,今年新增了三个关于 App Store Server Notifications 的 API,在本文的后续章节会有简要的应用案例。如果读者想了解这部分的详细更新内容,可以参考 What’s new with in-app purchase - WWDC22。
接下来讲解 App Store Server API 如何与开发者的服务器交互,正如前面说的,API 需要 originalTransactionId
作为查询的参数,具体可以怎么样获取?我们先来看 Original StoreKit 从哪里获取。
客户端将 Original StoreKit 获取的 App receipt
发送到开发者服务器,开发者服务器调用苹果的 verifyReceipt
API 进行解析,根据苹果服务端返回的票据内容中的 in_app 、latest_receipt_info 和 pending_renewal_info 字段都包含 originalTransactionId
参数。
那么 Original StoreKit 怎么结合 App Store Server API 一起使用,原有的 verifyReceipt
API 验证流程保持不变。具体的交互流程,首先是开发者 app 根据用户充值成功时获取的 App receipt 发给开发者服务器后,通过 verifyReceipt
API 获取解码后的票据内容,然后通过 originalTransactionId
参数就可以调用 App Store Server API。对于原来的流程并没有影响,开发者可以通过 API 获取这个用户的交易或订阅信息,包括订阅续订详细信息等。
StoreKit 2 获取 originalTransactionId
通过新 API transaction.originalID
获取,但需要注意只支持 iOS 15 或更高的系统版本。
当然也可以通过服务端获取,例如客户端提供的签名的 JWS transaction 的解析,或者是调用 App Store Server API 或 App Store Server Notifications 回调等等。例如 JWS transaction 中的 Payload 中就有 originalTransactionId 字段:
StoreKit 2 使用 App Store Server API 更加简单,因为不需要调用 verifyReceipt
API,所以直接调用 App Store Server API 就可以。与 Original StoreKit 一样不影响开发者服务端现有的票据验证流程。
最后,我们总结一下在 Original StoreKit 和 StoreKit 2 中使用 App Store Server API 的流程。首先 App Store Server API 支持 Original StoreKit 和 StoreKit 2,并且不需要依赖其它的接口,只需要 originalTransactionId
参数。而这个参数在 Original StoreKit 的 App receipts 中可获取,在 StoreKit 2 中的 Signed transactions 中可获取。所以,App Store Server API 的使用就是这么简单。
这里还想重点提醒一下,使用 Original StoreKit 的开发者服务器,以前从票据(App receipt)中解析 latest_receipt
来获取订阅的最新状态,而现在可以通过 originalTransactionId
请求 Get All Subscription Statuses
API 获取相应订阅的最新状态,相比以前通过客户端刷新或者等待苹果服务器推送通知的方式,更加灵活和高效。
以上就是将 App Store Server API 与 Original StoreKit 和 StoreKit 2 一起结合使用的案例。接下来,我们一起看看怎么调用 App Store Server API。
App Store Server API 为什么使用 JWT(JSON Web Tokens) 作为身份验证参数呢?
其实 JWT 是目前最流行的跨域认证解决方案,什么是跨域认证呢?如今的互联网服务都离不开用户认证,在解答这些问题之前,我们先来看看实现一个用户认证的流程:
1 | 1、用户向服务器发送用户名和密码。 |
这种流程存在什么问题?扩展性不好,无法适应现在的服务端架构。如果只是单台服务器是没有问题,但如果是服务器集群,或者是跨域的服务器架构,就要求 session 数据共享,每台服务器都能够读取 session。
session 在多个服务器之间共享就是最大的问题,服务器间要做到实时共享 session,另外不同业务的服务器可能 session 逻辑不一样,可能无法做到共享。所以另一种方案是服务器索性不保存 session 数据,所有数据都保存在客户端,每次请求都发回服务器。JWT 就是这种方案的一个代表。
JWT 是一个开放式标准(规范文件 RFC 7519),用于网络主机之间以 JSON 对象安全传输信息。而 JWS 是其中的一种实现规范(规范文件 RFC 7515),表示签名过的 JWT。也就是说,可以通过 JWS 验证信息是否被篡改,用于验证内容的真实性。
JWT 由三部分组成,通过点号 .
进行分割。每个部分都是经过 Base64Url 编码的字符串。第一部分 (Header) 和第二部分 (Payload) 在解码后应该是有效的 JSON,最后一部分 (签名) 是通过指定的算法得到在前两部分上所得到的签名数据。
JWT 格式:
1 | base64(header) + '.' + base64(payload) + '.' + sign( Base64(header) + "." + Base64(payload) ) |
这样说可能比较抽象,我们举一个例子来说,假设我们需要创建一个身份认证的 JWT 字符串:
header 内容:
1 | { |
payload 内容:
1 | { |
因为 header 算法是 HS256
,所以假设 secret 设置为 123456,则可以得到最终的 JWT 编码后的字符串:
1 | eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyLlp5PlkI0iOiJpSFRDYm95Iiwi6KeS6ImyIjoi566h55CG5ZGYIiwi5Yiw5pyf5pe26Ze0IjoiMjAyMuW5tDbmnIgzMOaXpTDngrkw5YiGIn0.vZhFBP0EIP2pE29X_7G_1dM7JflIRFouJcXjjo_BAnM |
具体要怎么验证 JWT 是否合法,开发者可以根据 JWT 的规范自行解析,也可以使用验证 JWS 的第三方库,可参考 jwt.io 网站的 JSON Web Token Libraries,也可以使用 jwt.io 在线网站进行验证:
但是 HS256 算法加上一个密钥即可,这种方式严格依赖密钥,但在分布式场景,可能多个服务都需要验证 JWT,若要在每个服务里面都保存密钥,那么安全性将会大打折扣,如果密钥一旦泄露,任何人都可以随意伪造 JWT。所以,应该怎么保证呢?
JWT 的原理现在读者应该了解基本知识了,保证数据未被篡改,JWS 核心就是签名,而检查签名的过程就叫做验证。更通俗的理解,就是对应前面提到的 JWT 的第三部分 Signature,如何保证数据不被篡改,那么就需要使用数字签名,它保证只有信息的发送者才能产生的别人无法伪造的一段数字串,一般是非对称密钥加密技术与数字摘要技术的结合应用,目前在数字签名中使用的三种非对称算法有 RSA
、DSA
和 ECDSA
。
严格来说,JWT 有两种实现,分别是 JWS (JSON Web Signature) 和 JWE (JSON Web Encryption)。由于 JWS 的应用更为广泛,所以一般说起 JWT 大家默认会认为是 JWS。JWS 的 Payload 是 Base64Url 的明文,而 JWE 的数据则是经过加密的。相对地,相比于 JWS 的三个部分,JWE 有五个部分组成。JWT 还有很多值得探讨的内容,本文只能简单介绍原理,读者可以参考阅读 引用 1、引用 2。
接下来我们讲解 JWT 的使用细节,JWT 是调用 App Store Server API 必须生成的签名参数。App Store Server API 使用的前提条件:
具体来说,JWT 签名分为三个部分,用句点分隔,Base64 编码的 header(签名头)、 Base64 编码的 payload(有效负载)和 signature(签名)组成,最后的签名部分,根据 header 定义的签名算法和类型进行签名。
具体 JWT 字段的含义:
字段 | 含义 | 字段值说明 |
---|---|---|
alg | Encryption Algorithm,加密算法 | 默认值:ES256。App Store Server API 的所有 JWT 都必须使用 ES256 加密进行签名。 |
kid | Key ID,密钥 ID | 您的私钥 ID,值来自 App Store Connect 的内购密钥页面。 |
type | Token Type,令牌类型 | 默认值:JWT |
iss | Issuer,发行人 | 您的发卡机构 ID,值来自 App Store Connect 的 API 密钥页面。 |
iat | Issued At,发布时间 | 秒,以 UNIX 时间(例如:1623085200)发布令牌的时间 |
exp | Expiration Time,到期时间 | 秒,令牌的到期时间,以 UNIX 时间为单位。在 iat 中超过 60 分钟过期的令牌无效(例如:1623086400) |
aud | Audience,受众 | 固定值:appstoreconnect-v1 |
bid | Bundle ID,套装 ID | 您的 app 的套装 ID,即 app 包名 |
生成 JWT 还需要生成一个私钥文件,可以参考苹果文档 Creating API Keys to Use With the App Store Server API。一般生成 JWT token 我们会通过第三方库来生成,可以参考 JSON Web Token Libraries。具体请求可参考上图的 curl
命令示例,替换 ${token}
和 ${originalTransactionId}
就可以。
关于 App Store Server API 苹果怎么验证我们的生成的这个 JWT token 是否可信呢?我们在苹果后台生成 .p8
格式的私钥文件,苹果服务器保存了公钥文件,当我们请求 App Store Server API 时,苹果根据公钥文件就可以验证 JWT 是否可信。当然开发者也可以自己验证,首先执行下面命令,把 .p8
私钥文件导出公钥文件:
1 | openssl ec -in AuthKey_123ABC456.p8 -pubout -out AuthKey_123ABC456_public.p8 |
然后可以在 jwt.io 网站选择 ES256
算法后,复制 JWT token 和公钥文件的内容到网页,就可以看到验证结果。
关于 App Store Server API 请求的细节,可以参考苹果文档 Generating Tokens for API Requests,或这篇实践教程 App Store Server API 实践总结。
WWDC21 推出的 StoreKit 2 的交易票据(receipt)是使用 JWS(JSON Web Signature) 格式签名。JWS 表示签名过的 JWT,也就是说,可以通过 JWS 验证信息是否被篡改,用于验证内容的真实性。关于 JWS transaction 的校验,其实从去年开始就有非常多的开发者吐槽,不知道如何校验:
现在苹果对验证 StoreKit 2 已签名的交易票据(JWS transactions)进行了详细的解答,大概分为三步:
alg
字段确定使用的签名算法 x5c
确认签名的证书链首先 x5c
表示 X509 证书链,X.509 是一种证书标准,主要定义了证书中应该包含哪些内容。其详情可以参考 RFC5280,SSL 使用的就是这种证书标准。同样的 X.509 证书,可能有不同的编码格式,目前有以下两种编码格式:
—–BEGIN…
开头,—–END…
结尾,内容是 BASE64 编码。那么 x5c 证书链成功验证,就表示这个签名的 JWS 是可信的,所以,x5c 证书链的规范如下:
所以,x5c 证书链的生成,简单来说,苹果的根证书(只能从苹果下载,相当于信任)签名包含了中间的证书,中间的证书签名包含了叶证书,而叶证书就是签名 JWS 内容的证书。证书链签名规则如下:
所以验证 x5c 证书链,就是反过来,我们验证叶证书是由中间签名证书签名的,然后确保中间签名证书是由根证书签名的,最后,根证书与 Apple 证书颁发机构提供的证书相匹配。如果这些步骤都验证成功,则整个 x5c 链验证就可以认为是合法的证书链。如果有证书不匹配,则不应该信任该链。
原理讲清楚后,那么我们应该怎么验证证书链呢?最简单的方法是使用 OpenSSL 命令验证 x5c 证书链。具体命令的参数 -trusted
带上信任的根证书,这里是苹果的 Apple Root CA - G3 Root,可以在苹果网站下载 Apple PKI 证书。参数 -untrusted
就是中间证书和叶证书。
执行这个 openssl verify -trusted xxx.pem -untrusted xxx.pem leaf.pem
后,根据返回的结果码判断,如果表示验证不成功,则此 JWS 数据可能被篡改且不应使用。
注:苹果网站下载的 AppleRootCA-G3 是
.cer
格式,需要把 .cer 转换成 .pem 格式,转换命令:openssl x509 -inform der -in AppleRootCA-G3.cer -out AppleRootCA-G3.pem
这里补充说明一下,在苹果 Apple PKI 证书网页有四个苹果根证书,为什么使用 AppleRootCA-G3 这个根证书呢?
证书 | 证书组织 | 签名算法 |
---|---|---|
Apple Inc. Root | Apple Inc. | 带 RSA 加密的 SHA-1 |
Apple Computer, Inc. Root | Apple Computer, Inc. | 带 RSA 加密的 SHA-1 |
Apple Root CA - G2 Root | Apple Inc. | 带 RSA 加密的 SHA-384 |
Apple Root CA - G3 Root | Apple Inc. | 带 SHA-384 的 ECDSA 签名 |
所以从表格可以看出,因为苹果 JWS 使用 ES256
算法,所以只能使用 AppleRootCA-G3 这个根证书。另外大家可能看到 Apple Computer, Inc.
,因为 2007 MacWorld 大会上,乔布斯亲自推出传闻已久的 iPhone 手机,为消除公司只生产电脑的形象,将 苹果电脑公司
改名为 苹果公司
,所以这个根证书还保留着(目前这个证书有效期是 2005 年至 2025 年),不清楚过期后苹果还否会更新这个证书呢?
验证了 x5c 证书链,还要用叶证书,验证一下 JWS 签名内容是否正确,至此签名验证成功后,就表示 JWS 内容可信。示例代码如下:
关于验证 JWS 的第三方库,可以参考 jwt.io JSON Web Token Libraries。
接下来,我们回顾一下,从 Original StoreKit 的 verifyReceipt 接口迁移到 App Store Server API 的使用案例。
所以,获取订阅品项的最新状态的交互流程如图:
通过 App Store Server API 的 /inApps/v1/subscriptions/{originalTransactionId}
接口获取订阅品项的最新状态,包含最新的签名交易票据和续订更新信息等。
接下来,我们来看获取最新交易状态的案例。获取最新交易票据,可以知道用户购买了什么品项、订阅了什么品项,或者续订了什么品项等。
对于用户来说,交易票据的状态获取有两种情况:
in_app
和 latest_receipt_info
获取Get transaction History
接口条件过滤获取App Store Server API 的条件过滤功能,可以参考 What’s new with in-app purchase - WWDC22。
所以,获取最新交易票据状态的交互流程如图:
如果读者想进一步了解这个流程的客户端代码具体该如何实现,可以参考 What’s new in App Store Connect - WWDC22
最后,我们来说一下 appAccountToken
的更新。appAccountToken
字段是 StoreKit 2 交易票据提供的开发者 app 与用户绑定关联的 UUID。在已签名的交易票据、已签名的续订和该交易的苹果服务器通知中都会包含。
以前的 Original StoreKit 是不支持 appAccountToken 字段,因为它是 StoreKit2 的新功能。而现在,苹果增加了对 Original StoreKit 中的 applicationUsername
字段中提供 UUID 支持,从而让服务端不需要区分 Original StoreKit 还是 StoreKit 2,都可以支持 appAccountToken 所做的逻辑功能。详细的更新介绍,可以参考文章 苹果内购录:关于透传字段的一些讨论。
以上就是本次 session 关于 App Store Server API 部分的更新。
接下来,我们讲解 App Store Server Notifications 内容的更新。
关于 App Store Server Notifications 的内容,将从以下四方面进行讲解:
首先,App Store Server Notifications V2 兼容 Original StoreKit,并且全面支持应用内购买数据。详细的更新内容,可以参考我们之前的文章:IAP 后台通信优化与实践。
如何配置 App Store Server Notifications 来接收通知,可以在 App Store Connect 中的应用页面,看到配置的部分:
可以分别配置生产和沙盒环境的回调通知链接,然后每个链接的配置,可以设置 V1 或 V2 版本的通知。
这里建议如果开发者现在使用的是 V1 版本的通知,迁移到 V2 版本前,先配置一个沙盒环境的 V2 链接进行测试,测试通过后,再切换到生产环境的 V2 版本。
接口通知的链接,需要注意服务器配置:
App Store Server Notifications V2 版本通知的内容是 JWS 格式,所以需要验证签名:
签名证书验证可信后,可以读取 payload 的内容:
这个内容字段,需要开发者注意一下,notificationUUID
字段是每个通知的唯一标识符,如果服务器重试通知,则重试通知包含相同的 notificationUUID,有助于开发者服务器处理了通知但没有及时响应时接到到重复通知内容的情况。signedDate
字段是每个通知的创建时间,这对于检测重试通知也特别有用,具体作用下文会讲解。appAppleId
和 bundleId
可以用于验证 app 是否为开发者的。
App Store Server Notifications V1 版本虽然现在还可以使用,但是苹果强烈建议开发者升级迁移到 App Store Server Notifications V2,因为 V2 版本增加了更多的状态通过,并且是支持 Original StoreKit 版本,完成是兼容性迁移,不会很麻烦,收益也更好。具体 V1 和 V2 的区别和优劣势,可以参考文章:IAP 后台通信优化与实践。
App Store Server Notifications V2 增加了新的类型和添加新的子类型字段,从而提高所提供的通知场景更加详细并扩展更多的情景,以下这个示例就是订阅品项的生命周期的每一步提供通知:
上面这个流程图,我们假设一个用户订阅成功后,开发者可能收到 SUBSCRIBED
类型和带有 INITIAL_BUY
子类型的通知,或者用户使用了优惠订阅,则收到 OFFER_REDEEMED
类型和带有 INITIAL_BUY
子类型的通知,通知中包含首次交易的票据和订阅的续订信息。
时间流逝,用户一直订阅续订,所以一直处于续订状态(Renewing subscription)。每次续订时,苹果都会发送一个 DID_RENEW
通知,其中包含新的(支付成功)的交易票据。而当用户停用自动续订时,订阅进入即将到期的订阅状态时(Expiring subscription),开发者将收到 DID_CHANGE_RENEWAL_STATUS
类型和带有 AUTO_RENEW_DISABLED
子类型的通知。最后,如果用户不重新启用自动续订,则在订阅到期时,订阅会进入过期状态(Expired),开发者将收到 EXPIRED
类型和带有 VOLUNTARY
子类型的通知。
还有 Pending price increase
(订阅涨价)、Grace period enabled?
(启用宽限期)/ Grace period
(账单宽限期)、Billing retry
(扣费重试)等通知,另外这个流程图没有展示订阅退款通知和订阅撤销通知等场景。
所以可以感受到,App Store Server Notifications V2 通知覆盖了大量场景,可以通知开发者订阅品项的生命周期的每个步骤,苹果也在努力覆盖更多的过渡状态,希望给开发者提供更有价值的通知。最后,关于 App Store Server Notifications 全部的通知类型,可以阅读苹果 App Store Server Notifications 文档。
App Store Server Notifications 是开发者被动接收通知,所以总会有开发者的服务器出现故障的情况,时间可能是几分钟,甚至是几天。所以总有错过接收通知的情况,所以,现在我们可以通过一些方法来解决这个问题了!
例如你的服务器,接到到 1 和 2 的通知,然后服务器宕机等,导致 3、4、5 通知无法接收,然后服务器恢复了,接收到 6 通知,然后 3 和 4 通知可能会晚于 6 通知,5 晚于 7 通知等情况。
那么针对上述这种情况,有几种方法可以处理。
首先,苹果将 App Store Server Notifications V2 通知的重试策略进行了调整,在首次尝试通知后没有收到来自开发者服务器的 200 回复时,则会按如下方式重试::
增加了两次重试次数,并且时间缩短到第一次重试为 1 小时后,对于开发者来说,一般的服务器故障能在一小时内容恢复,所以一小时后重试更加有效。
这里就有一个疑问,如何检测通知是原始通知还是重试通知?开发者可以检查通知里的 signedDate
字段,它表示通知的签名时间,也就是说通知发送的时间,通过对比通知里的这个字段与当前接收到的时间,就知道这个通知是否为重试通知。
比如,通知 6 和通知 3,服务器先收到 6 通知,并不意味着 6 比 3 通知早。比如通知 6 是用户取消订阅,通知 3 是用户续订订阅,所以开发者要通过 signedDate
字段,确保通知的顺序逻辑正确。
另外通知会重试,所以可能会存在重复通知的情况,所以请务必检查通知的 notificationUUID
字段,如果发现重复的 UUID,可以删除这些重复数据。
最后,我们来看看 App Store Server API 今年新推出的 Get Notification History
(获取通知历史记录) API,它提供了六个月内的苹果服务器发送通知的历史记录查询。关于这个 API 的详细介绍,可以参考 What’s new with in-app purchase - WWDC22。
获取通知历史记录接口允许在特定时间跨度内进行查询,比如开发者服务器宕机解决后,可以使用开始和结束时间戳来查询宕机期间所有未接收到的通知。查询时间参数格式如下:
当然,考虑到宕机时间如果很久,可能会有很多未接收的通知,所以也可以指定具体的通知类型进行过滤。比如 notificationType
设置为 DID_RENEW
通知类型来查询订单更新的通知。
最后,还可能通过 originalTransactionId
过滤到特定用户。
通过 Get Notification History
(通知历史记录)接口,可以方便开发者获取到错过的通知,当处理用户反馈订阅状态与预期不同时,获取通知历史记录在客户支持中也非常有帮助。最后回顾一下接口的返回内容,这里简单起见,只列出部分字段内容:
可以看到 notificationHistory
数组中每一条就是一个通知,signedPayload
就是签名的 JWS 通知内容,firstSendAttemptResult
字段表示苹果服务器记录的初始通知的响应结果,比如通知成功的情况下,这个值是 SUCCESS
,但是可能开发者服务器配置或者宕机等,会有不同的值,比如我们这里的 SSL_ISSUE
,表示开发者服务器的 SSL 证书或进程存在问题。所以,除了看到通知未发送成功之外,此字段还提高了诊断服务器问题的可见性。
所以,如果开发者刚刚接入 App Store Server Notifications,那么开发者服务器并没有用户之前的通知历史记录,那么就可以使用 Get Notification History
接口获取之前的通知历史记录,这也是接口的作用之一。
另外,苹果新提供的 Get Test Notification Status
API 也具有相同的 firstSendAttemptResult
字段,方便测试通知时诊断。详细可以参考 What’s new with in-app purchase - WWDC22。
最后让我们来了解一下,怎么通过通知了解用户购买或取消的原因,从中洞察商业机会。比如 App Store Server Notifications V2 提供了一些新的通知子类型,比如 EXPIRED
或 DID_CHANGE_RENEWAL_STATUS
。
例如 EXPIRED
类型,开发者一般收到通知后,会将用户的订阅标记为过期并撤销对产品服务的访问权限。但是,了解用户过期的原因通常很有用。是由于扣费问题、自愿取消还是订阅价格上涨?
另一个通知 DID_CHANGE_RENEWAL_STATUS
也是获得额外信息和机会的一个很好的例子。表面上收到这个通知,表示用户的订阅状态更新了,表面上开发者不需要采取任何的操作,相比 EXPIRED 通知,优先级可能更低,但这往往是错误的理解!这个通知是一个机会!
首先,此通知是尝试在订阅到期之前赢回客户的绝佳机会。特别是由于停用自动续订可能发生在 app 之外,这可能是在到期日期之前续订状态更改通知的另一个唯一触发的通知。
此外,这个通知还提供对客户行为的洞察。可用于确定订阅者在续订期间何时取消。是订阅到期前一天吗?新订阅者是否会在注册您的服务后立即停用自动续订?此类信息对于了解取消的原因和改进您的产品非常重要。
最后,某些场景可能永远不会有通知,但是通过查询用户的订单历史中有记录。例如,用户可以在订阅期到期之前停用但随后重新激活自动续订,由于这一切都发生在订阅期内,因此不会影响订阅的长期状态,所以可能不会有通知。
总体而言,App Store Server Notifications V2 通知通过在用户订阅周期的每一步提供信息来增强和创造了解客户行为的机会,覆盖比以往更多的场景。
最后,总结一下今天的内容:
从去年推出 StoreKit 2、App Store Server API 和 App Store Server Notifications V2,到今年的优化完善,都是开发者们一直以来期待的功能,现在苹果已逐步完善应用内购买(IAP),相信读者都有所感受。另外,随着应用市场的存量饱和,竞争越来越激烈,获取一个新用户或者挽留一个付费用户的成本很高,所以,苹果也希望开发者能根据这么新 API 的特性,尽早的推进服务端使用这些新的 Server API,对于获得用户的购买行为和感知体验,有更敏捷的洞察力和更准确的预流失风险评估等。总之,善待每一个用户,提升用户体验,是突出重围和赢得用户的绝佳方式。
本文首发于 WWDC22 开发者需要关注的重点内容 - 掘金,欢迎关注我们 @37手游iOS技术运营团队 。
作者:iHTCboy
iOS 16 系统新特性,WWDC22 开发者,需要关注的重点内容、注意事项等,快速了解最新内容和需要适配的最新情况。
从用户角度:
从开发者角色:
系统详细更新日志:
详细教程:
与我们游戏或开发有关的注意事项
在 iOS16 以前,添加设备到证书的开发者app,默认是允许自由打开。
而在 iOS 16,增加了“开发者模式”,顾名思意,跟安卓一样,开启开发者模式,才能调试系统的一些能力。
打开“开发者模式”,在设置 -> 隐私与安全性 -> 开发者模式,默认是关闭状态。
点击开启后,会弹窗,需要确认后,设备需要重启后才能生效!
并且,设备重启后,系统还会弹窗2次确认,是否开启。并提示开启会“your device security will be reduced.
”(降低系统的安全性)。
目前测试,企业证书签名的 app,不受“开发者模式”影响,只需要单独信任证书即可打开。
目前“开发者模式” 影响 TestFlight 安装的包含,不开启 “开发者模式”,无法打开:
目前苹果文档显示为已知问题,可能下一版本修正。
iOS & iPadOS 16 Beta Release Notes | Apple Developer Documentation
因为 Xcode 文档指出,这项功能不会影响从 App Store 购买 app 或参加 TestFlight 团队等普通安装技术。相反,开发人员模式专注于在Xcode中执行Build和Run,或使用 Apple Configurator 安装 .ipa
文件等场景。在这些情况下,设备会明确要求使用它的人确认他们是开发人员,并意识到安装开发签名软件的风险。
苹果表示,iOS 16 和 watchOS 9 中引入的开发者模式可保护人们免于在设备上无意中安装可能有害的软件,并减少了仅由开发者功能暴露的攻击载体。
详细可以查看 Xcode 文档:Enabling Developer Mode on a device
App Tracking Transparency
Known Issues
The IDFA isn’t provided to apps even if the App Tracking Transparency status is Authorized. (93978371)
即使允许了跟踪,也获取不到 IDFA。
Apple ID Authentication
Known Issues
In certain cases, such as after unlocking a device from Lost Mode, an Apple ID authentication might be blocked and Apple ID services rendered nonfunctional. The user is redirected to Apple ID Settings to perform an authentication, but no authentication request is ever visible to the user. (93980441)
Workaround: Rebooting the device allows the authentication to proceed.
可能无法使用 Apple ID 认证,临时解决方法,重启设备。
Attempting to set an orientation on
UIDevice
viasetValue:forKey:
isn’t supported and no longer works. (93367651)
不支持通过 setValue:forKey: 在UIDevice上设置方向,也不再有效。需要开发者检查是否有使用此方法,可能后续版本将不能使用。
iOS 14 开始,app 读取剪贴板时,在 app 的顶部会显示一行提示内容:
在 iOS 16 开始,当 app 要读取剪贴板;会被明确询问用户是否要允许它。
注: 目前没有永久授予或永久拒绝的配置
,是系统层控制,也不需要开发者声明。所以,每次 app 尝试读取您的剪贴板时,都会弹出一次这个弹窗!
安装包减少了30%,从 10GB 降到 7 GB,因为其它平台在打开时可选择在下载安装。
因为为了最大限度地减少Xcode的下载大小,Xcode14 及更高版本不包括 watchOS 和 tvOS 的模拟器运行时。打开时可选择再下载安装。
另外,可以在苹果开发者网站单独下载:
然后通过命令行安装:
1 | xcode-select -s ~/Downloads/Xcode-beta.app |
编译更快,可以查看每个类的编译耗时。
跨平台设计,一套 app 图标自动适配 iOS,iPadOS,macOS, tvOS 等。iOS 只需要一张 1024 px 图片即可。
注:如果只使用一张 1024 x 1024 图标,则 Target version 只支持 iOS 12+ 以上系统!
否则上报 iap 包体会报错:
Invalid bundle. The app at “Product.app” contains a single-size app icon but has a value of 11.0 for the MinimumOSVersion key in its Info.plist file. Include all app icon sizes to support iOS 11.0 or later, or update the iOS Deployment Target to 12.0 or later to support uploads with a single-size app icon. (90961)
以上就是我们升级 iOS 16 后,了解到的重点关注的内容更新,大家如果有更多发现,欢迎评论区一起分享~
]]>欢迎关注我们,了解更多 iOS 和 Apple 的动态~
本文首发于 苹果 AppStore 财年和账单那些趣事 - 掘金,欢迎关注我们 @37手游iOS技术运营团队 。
作者:iHTCboy
本文带你了解苹果 AppStore 的财年和账单周期,关于 AppStore 开发者账单和收入,相信很多开发者不一定有接触,或者接触时还是有很多疑问没有时间来学习。另外,还会有一些财年的诡计问题,比如为什么阿里巴巴财年是从4月1号到次年的3月31号呢?苹果财年为什么这么奇怪,本文一一为你解答~
在苹果网站 公司新闻 页面会通告每个季度业绩:
如果你有思考或好奇心,一定会有疑问:苹果的季度业绩为什么时间这个早?2022 年 1 月 27 日(北京时间)竟然公告的是 2022年Q1的业绩???跟我们平常理解的自然年的季度划分不一样,比如我们通常认为,2022年 Q1 会是 2022年1、2、3月。
所以,为什么会出现这样问题呢?这就是我们本文要介绍的其中一个关键点。
财年(Fiscal Year,财经年度,财政年度,会计财务年度,会计年度),是指公司或国家每年制定预算
或计算收入
的统计时间。财季是指某一季度的财务状况,财年是指某一完整四个财季的财务状况。但每个国家或其法例所辖的组织各有不同,大抵分成两类:
财年类型 | 定义 | 采用的国家或地区 |
---|---|---|
历年度制 | 指财政年度的起止期与年历始末相同,即公历1月1日起至12月31日止。 | 中国、德国、法国、波兰、匈牙利、朝鲜、南斯拉夫等 |
跨年度制 | 指财政年度起止期与年历始末不相同。 | 英国、奥地利、日本、加拿大、印度等国家和地区是自4月1日起至次年3月31日止。 瑞典、埃及、澳大利亚、巴基斯坦、孟加拉国、苏丹等国家是自7月1日起至次年6月30日止。 美国在1976年以前是自7月1日起至次年6月30日止, 1976年以后改为自10月1日起至次年9月30日止。 |
参考维基百科 财政年度,各国/地区的财政年度列表:
从图中可以看到,美国政府的财年是从10月1日起至次年9月30日止。
有一个约定俗成的问题,对于财务年度不在12月结束的公司,其财务报表会将结束日期所在的自然年称为其财务年度。来源
例如 Alibaba 在 3 月 31 日为其 fiscal year end,那就会写 fiscal year ended on March 31rd, 2015 = Fiscal2015。
那么为什么阿里巴巴财年是从 4 月 1 号到次年的 3 月 31 号呢?
阿里巴巴于2014年在美国上市,但并没有按美国的习惯来发年报,其原因是为了配合最大股东软银 softbank 并表需要。因为日本软银财年截止时间是 3 月 31 日。(可以看上图,日本的财年周期时间)
所以,到这里大家对于财年就有了大概的了解,虽然美国政府的财年在1976年以后改为自10月1日起至次年9月30日止。但美国的企业并不都是按照这个月份来定,比如苹果是 Sep28 End(9月28日,但并不是固定,下文会解析), 沃尔玛是 Jan31 End(1月31日)。
所以,AppStore 账单也是按照苹果财年来定的,可以通过以下链接获取 AppStore 账单日历(注:需要苹果开发者账号登陆才能访问
):
注:也可以在 App Store Connect 后台找到入口:付款和财务报告 -> 选中日期 -> 最下方有一个 “查看财务日历” 入口。
问题又来了!这个图怎么看?
苹果账单周期的规则,有2条大的规律:
35
天,两个 28
天月。我们以 2022 年苹果财年来例,如下图所示:
苹果 2022 年财年,以 Q1 为例:
而每个月的账单月,也并不是自然月,Q1 季度的3个账单月:
同理,其它季度的也一样,这里就不展开了,大家可以在看看上图消化理解一下,其实并不难懂哈~
如果觉得文章不错,可以顺手给个点赞哈~
当然,苹果账号的规律 还有很多细节:
苹果每 5 年必须在 12 月的账单月增加一周
。小编这里收集整理了苹果财务日历:2009年~2022年:
根据上文 2.3 最后一点提到:苹果财务日历只有364天,而正常年有365和366日,所以,苹果每5年必须在12月的账单月增加一周。
2017年周期增加了一周:
所以,计算一下 2017 +5 年 = 2022 年,但 2022 年财年如上文提到,22Q1并没有增加多一周,估计2023年增加?
大家可能不理解,这一周的增加意味着什么?
@David Barnard 在推特上写道:
With Apple likely grossing >$1B/day, that’s >$7B shifted from Q1 2022 to Q1 2023. Analysts do take note of this extra week and how it impacts revenue, but I’ve never seen a chart that tried to correct for it, so all the charts just make it look like an especially good quarter.
由于 Apple 可能每天收入 >1B 美元(十亿),即 >7B 美元(七十亿)从 2022 年第一季度转移到 2023 年第一季度。分析师确实注意到这额外的一周以及它如何影响收入,但我从未见过图表试图纠正它,所以所有的图表都让它看起来像是一个特别好的季度。
事实上,一个组织能够采取的任何一个会计年度连续12个月内组成。这一规则的一个可接受的变化是采用了52个星期的年度报告的时期。而苹果公司,会根据本身的在一年内销量很大的季节变化往往选择自己利于自己的财年,这对于开发者来说可能是一个 “陷阱”,也是一个 trick!
综上,所以苹果的账单周期大概是这样的流程:
这个流程图有很多细节内容,这里就不展开了,大家有问题,可以在评估区交流啊~
引用来源:App Store大陆开发者收款总结
这个问题在上文 “2.5 AppStore 账单” 流程图可以看出,每个环节都会有影响:
关于这个问题,最近发现还有一个原因,苹果账单报告数据里,有 2 个字段:
字段名称 | 日期类型 | 备注 |
---|---|---|
交易日期 | MM/DD/YYYY | 顾客购买 App 或 App 内购买项目的日期。仅当交易日期距离结算日期不超过 30 天时,才显示交易日期,否则该字段为空。 |
结算日期 | MM/DD/YYYY | 处理和收取顾客付款并开具发票的日期。 |
苹果出账单的报告,是按结算日期来出账单。开发者的订单日期与苹果账单的交易日期一致,但因苹果账单月不是自然月,并且账单是以结算日期为准,导致数据对不上的问题。
中国内地目前最低付款门槛为 150 美元
,也就是大概超过 1000 CNY(人民币)时会收到苹果打款。
如果您的银行所在国家或地区、银行帐户货币列于下表中,则您获得付款的最低门槛为 0.02 美元。
银行所在地区代码 | 银行所在地区 | 银行帐户货币 | 银行所在地区代码 | 银行所在地区 |
---|---|---|---|---|
AD | 安道尔 | EUR | IS | 冰岛 |
AN | 荷兰 | EUR | IT | 意大利 |
AT | 奥地利 | EUR | JP | 日本 |
AU | 澳大利亚 | AUD | LI | 列支敦士登 |
AZ | 阿塞拜疆 | EUR | LT | 立陶宛 |
BE | 比利时 | EUR | LU | 卢森堡 |
BR | 巴西 | BRL | MC | 摩纳哥 |
BG | 保加利亚 | EUR | ME | 黑山共和国 |
CA | 加拿大 | CAD | MM | 缅甸 |
CC | 科克斯(基灵)群岛 | EUR | MQ | 马提尼克岛 |
CH | 瑞士 | CHF | MT | 马耳他 |
CH | 瑞士 | EUR | MY | 马来西亚 |
CY | 塞浦路斯共和国 | EUR | NL | 荷兰 |
CZ | 捷克共和国 | EUR | NO | 挪威 |
DE | 德国 | EUR | NZ | 新西兰 |
DK | 丹麦 | EUR | PH | 菲律宾 |
EE | 爱沙尼亚 | EUR | PL | 波兰 |
ES | 西班牙 | EUR | PM | 圣皮埃尔和密克隆群岛 |
FI | 芬兰 | EUR | PT | 葡萄牙 |
FR | 法国 | EUR | RE | 留尼汪岛 |
GB | 英国 | EUR | RO | 罗马尼亚 |
GB | 英国 | GBP | SE | 瑞典 |
GF | 法属圭亚那 | EUR | SG | 新加坡 |
GP | 瓜德罗普岛 | EUR | SI | 斯洛文尼亚 |
GR | 希腊 | EUR | SK | 斯洛伐克共和国 |
HK | 香港 | HKD | SM | 圣马力诺 |
HU | 匈牙利 | EUR | US | 美国 |
ID | 印度尼西亚 | IDR | VA | 罗马教廷(梵蒂冈城) |
IE | 爱尔兰 | EUR | YT | 马约特岛 |
印度(INR)银行帐户的最低付款门槛为 0.30 美元。对于其他未提及的国家或地区、银行帐户货币,最低付款门槛为 150 美元。
另请注意,韩国(KRW)和泰国(THB)银行帐户的最低付款门槛如下:
韩国(KRW):根据当地规定和银行要求,最低付款门槛为 50 美元。
泰国(THB):泰国居民的最低付款门槛为 10 美元;位于泰国境外的开发者最低付款门槛为 150 美元,付款方式仍为电汇付款。
参考:最低付款门槛
2023年更新:
苹果更新了最低付款门槛,中国大陆最低门槛 40 美元。文档:https://developer.apple.com/cn/help/app-store-connect/reference/minimum-payment-threshold/
对于开发者来说,苹果付款到账后,并不是直接打开你的银行卡余额中,而是美元,所以需要结汇
。关于结汇,可以在手机银行 app 输,但可能第一次需要到银行柜台办理,具体可以联系你在苹果后台填写的银行卡所属银行咨询。
最后,苹果在中国大陆的内购商品销售并未扣税,所以结汇资金属性,按理是需要报个人所得税。具体,可与当前税务局咨询。
深入的财务报表和账单流程有非常专业和非常多的细节,这里就不展开了,因为小编可能也不懂!本文从一个财务报表的疑问开始,希望开发者,平时在做写代码的同时,对于可能与自己有关,又可能跟自己没有关的问题,可以多一个好奇心,多一个疑问,可能就多一份收获。
如果你觉得文章写的不错,欢迎点赞~ 欢迎评论区一起交流~
另外,WWDC 2022 将于北京时间 6 月 7 号开始,一般苹果会灰度上线一些新特性或功能,所以最近这些更新有可能会影响到生产环境,比如这2天的上传App 和 ASC 后台登陆就受到影响,服务出现了宕机无法使用的情况:
开发者们需要注意:最近 App 要多预留几天时间排期规划哈~
最后,我们团队接下来会持续关于 WWDC 22,给大家带来最新的动态,欢迎关注我们,回家不迷路哈~
欢迎关注我们,了解更多 iOS 和 Apple 的动态~
]]>注:如若转载,请注明来源。