蘋果增加投資欲解除 iPhone16 封殺令
前言
本期是 Swift 編輯組自主整理周報的第六十六期，每個模塊已初步成型。
Swift 周報在 GitHub 開源[1]，歡迎提交 issue，投稿或推薦內容。目前計劃每兩周周一發布，歡迎志同道合的朋友一起加入周報整理。
若你決定燦爛，山無遮，海無攔。Swift社區與你一起，用黑白兩色的眼睛，去觀察五彩斑斕的世界！??????
周報精選
新聞和社區：蘋果 1 億美元投資還不能解除 iPhone16 封殺令？
提案：SE-0453: 向量，固定大小的數組提案正在審查。
Swift 論壇：提議修改和讀取訪問器
推薦博文：Swift 中間語言（SIL）的生成和使用
話題討論：
AI 技術迅速發展壯大你有怎樣的看法呢？
上期話題結果
圖片
從投票結果可以看出，大家對于消費還是保持理智。資本的套路不靈光了。
新聞和社區
蘋果 1 億美元投資還不能解除 iPhone16 封殺令？
2024 年 11 月 22 日
美股科技巨頭蘋果的最新款智能手機 iPhone 16 系列產品發售后不久便在印度尼西亞市場遭遇困境，目前，蘋果正尋求解除印尼對 iPhone 16 的銷售禁令。
這一禁令源于蘋果在印尼子公司的產品未能滿足 40% 本地化率的要求、也沒有獲得在該國銷售的許可，禁令的目的在于保護當地產業和就業。
此前，蘋果已經兩度提出過解決方案，最初是計劃在當地投資近 1000 萬美元擴大生產線，對此印尼官方并未做出多少回應，數日后蘋果再次提議兩年內將在印尼投資近 1 億美元，印尼方面雖有做出回應，但蘋果高管在飛到雅加達后，未能成功與該國工業部長會面。
據印尼當地媒體周五（11月22日）報道，該國工業部周四（11月21日）會見了蘋果公司的代表，討論了蘋果公司在兩年內投資 1 億美元的提議，據悉，這筆資金將用于投資該國的一個研發中心項目和專業發展學院，并且蘋果還計劃從 2025 年 7 月開始在當地生產配件產品組件，專門用于蘋果的 AirPods Max。
雖然蘋果新的報價已經是之前計劃的 10 倍，但印尼政府則是期望蘋果能夠在 1 億美元投資上再添上一點，以換取 iPhone 16 禁令的解封和更多準入。
工業部發言人 Febri Hendri Antoni Arif 周四在采訪中表示，“當然，從政府的角度來看，我們希望這筆投資更大。”
他表示，更大規模的投資將有助于印尼制造業的發展，并補充稱，印尼國內工業有能力支持蘋果產品的生產，比如充電器和配件。
Canalys 專注于蘋果戰略研究的分析師 Le Xuan Chiew 表示，雖然印尼對蘋果來說是一個小市場，但它也提供了增長機會，因為它擁有全球第四大人口。
他指出，年輕且精通技術、數字素養不斷提高的人口與蘋果擴大全球銷售的戰略是一致的，此外該國還提供了制造和組裝的潛力，支持蘋果實現供應鏈多元化的努力。
他還補充道，在這個市場取得成功需要長期的策略，蘋果的投資表明了遵守當地法規的承諾，并為未來的增長鋪平了道路。（來源：財聯社）
消息稱蘋果正評估電視新品類，智能家居是關鍵
2024 年 11 月 22 日
科技媒體 MacRumors 昨日（11 月 21 日）發布博文，援引彭博社馬克?古爾曼（Mark Gurman）的曝料，消息稱蘋果公司內部正評估設計和制造“蘋果品牌電視”的想法，進一步擴展智能家居生態。
消息稱蘋果公司正積極探索新的收入來源，加速推進智能家居戰略。該媒體認為蘋果的智能家居產品獲得成功，電視產品可能會出現在未來的產品路線圖上。
媒體報道，蘋果將推出智能電視的消息最早可以追溯到 2006 年，而一位前蘋果高管于 2011 年聲稱蘋果與一家電視制造商達成了協議，相關消息此后愈演愈烈。
喬布斯在談及電視時曾透露：“我終于搞定了，我想創造一款完全易于使用的集成電視，可以和 iCloud 無縫集成，用戶不用擺弄復雜的遙控器”。
相關消息已知持續到 2015 年，《華爾街日報》于 2015 年報道，蘋果公司在“1 年前”就放棄了蘋果品牌電視的計劃。
蘋果公司在 2019 年 11 月推出了 Apple TV+ 服務，并在過去五年中不斷增加新的電視節目和電影。Apple TV+ 現在擁有相當數量的內容，此外還有 Apple Music 等服務，可以構筑完善的電視生態。
在硬件方面，盡管電視市場仍然被三星、LG 和索尼主導，但蘋果公司一直研究尖端顯示技術，該媒體認為蘋果現在推出電視產品，依然可以吸引大量消費者。（來源：IT之家）
Billie Eilish 當選 2024 年 Apple Music 年度藝人
2024 年 11 月 21 日
Apple 今日宣布 Billie Eilish 當選 Apple Music 年度藝人，以贊頌這位唱作歌手于 2024 年全年帶來的卓越影響。
在這一年里，Billie 先是憑她為 Greta Gerwig 執導的影片《Barbie》創作并演唱的主題曲《What Was I Made For?》歷史性地第二次榮獲奧斯卡獎并捧得兩座格萊美獎，之后又發布了自己的第三張專輯《HIT ME HARD AND HIT ME SOFT》。這張既真誠又大膽的專輯代表了這位時代杰出藝人的重大飛躍，也是她音樂生涯迄今的最佳作品。這張專輯剛一發行就在全球 138 個國家和地區的 Apple Music 全類型專輯排行榜登上了冠軍寶座。
在那之后，Billie 繼續發揮她的文化影響力。今年 8 月，她代表家鄉洛杉磯在巴黎運動盛會的閉幕式上表演了金曲《BIRDS OF A FEATHER》，當天她的 Shazam 搜索量也創下了個人紀錄。Billie 還與 Charli xcx 合作了今夏的熱門單曲《Guess》。目前，她的《HIT ME HARD AND SOFT》巡演正在進行中，一票難求，將把這一年的輝煌成就延續到 2025 年。
今年，Billie 又獲得了包括年度制作、年度專輯、年度歌曲在內的七項格萊美獎提名。同時，她也成了首位兩度獲封 Apple Music 年度藝人的獲獎者——她在 2019 年曾當選首屆 Apple Music 年度藝人。
這一非凡成就不僅代表了 Apple Music 對 Billie 作品的熱愛，也反映了她的創作力之旺盛與持久。她 2019 年的首張專輯《WHEN WE ALL FALL ASLEEP, WHERE DO WE GO? 》今年五月被評為 Apple Music 百大最佳專輯第 30 名。這張專輯讓世界認識了一位不到 20 歲的天才藝人，而《HIT ME HARD AND SOFT》則證明，她絕非一閃而過的流星。
“從近十年前第一次聽到《Ocean Eyes》開始，我們一直是 Billie 的歌迷和支持者?！盇pple Music 內容與編輯高級總監 Rachel Newman 表示，“一位年輕藝人能在這么短的時間里打動這么多人的心，這是非常難得的。過去這一年里，她的演化讓我們嘆為觀止，這不僅是因為她的聲音和藝術繼續觸發著廣泛共鳴，更因為她如此勇敢坦蕩地綻放——按她自己的意愿，以她自己的方式。”
“從第一天開始，Apple Music 就支持著我的音樂和藝術。在音樂生涯的這個階段獲得年度藝人的認可，我感到榮幸之至。”Billie 告訴 Apple Music。現在，你可以通過空間音頻重溫 Billie 的全部作品，并慶祝她的非凡成就。同時，別忘了關注 Apple Music 揭曉在 2024 年大放異彩的藝人與歌曲，聆聽人氣歌單，以及獲悉更多 2024 年編輯精選專輯。
蘋果計劃2026年發布全新Siri：集成先進大模型 更像真人
2024 年 11 月 21 日
11 月 22 日消息，據媒體報道，蘋果正在研發更智能、對話能力更強的 Siri，旨在趕超 OpenAI 的 ChatGPT 及其他語音服務。
報道稱，新版 Siri 采用更先進的大型語言模型（LLM），蘋果希望新 Siri 能進行持續對話，更像人類一樣回應問題，更迅速處理更復雜的請求。
全新 Siri 被蘋果研發人員稱為“LLM Siri”，與今年推出的 Apple Intelligence（蘋果智能）一樣，這些新功能不會立即被納入明年的硬件設備中，蘋果目前計劃最早 2026 年發布新版 Siri。
據了解，在 iOS 18.1、iPadOS 18.1 和 macOS Sequoia 15.1 中，備受關注的 Apple Intelligence 功能正式上線。
iPhone、iPad 和 Mac 將擁有“全系統范圍內的 AI 寫作助手”——包括郵件、備忘錄、信息、Pages，以及第三方應用。
按計劃，蘋果 iOS 18.2 正式版將在 12 月發布，屆時，Apple Intelligence 將正式接入 ChatGPT。
蘋果用戶不用創建賬戶就可以免費使用 ChatGPT，Siri 將利用 ChatGPT 的專業知識回答用戶問題。（來源：快科技）
提案
正在審查的提案
SE-0452[2] 整數通用參數 提案正在審查。
在本提案中，我們介紹了在字面整數參數上對泛型類型進行參數化的能力。
SE-0453[3] 向量，固定大小的數組 提案正在審查。
本提案為標準庫Vector引入了一種新類型，這是一個固定大小的數組。這類似于經典的 C 數組 T[N]、C++ 的 std::array<T, N> 和 Rust 的數組 [T; N]。
Swift論壇
- 評論SF-0011：并發安全通知[4]
Swift Foundation 提案 SF-0011: 并發安全通知 的評審已開啟，將持續至 2024 年 11 月 19 日。該提案旨在通過新的 API 提升通知在并發場景中的處理能力，并引入以下三個協議：
- Message：基礎協議，用于定義通用消息結構。
- MainActorMessage：繼承自 Message，用于需要在主線程上接收的消息。
- AsyncMessage：繼承自 Message 和 Sendable，用于支持異步接收的消息。
同時，提案設計了兩種 addObserver 方法，分別處理 MainActorMessage 和 AsyncMessage。
關鍵反饋：
- 關于 MainActorMessage 的約束：
提案需要進一步澄清 MainActorMessage 的 post() 方法是否應被限制為僅在 @MainActor 環境中調用，以確保觀察閉包能夠同步觸發。
應明確 MainActorMessage 是否允許在非 @MainActor 環境中構建，但要求在主線程上觀察。
- 關于 AsyncMessage 協議的必要性：
有建議認為 AsyncMessage 協議的 Sendable 要求可能是多余的，可以直接使用 Message 協議，并通過對方法的參數施加約束來滿足需求。
如果未來語言支持動態隔離（如 @isolated(parameter)），可能可以通過 Message 協議中的屬性進一步簡化設計。
- 異步消息處理的優化建議：
當前的 addObserver 方法使用異步觀察者閉包，但該閉包可能通過非結構化任務執行，容易引發性能問題，例如過多任務創建銷毀會導致開銷增加，甚至可能導致拒絕服務攻擊。
建議通過結構化并發重新設計 API，例如引入 AsyncSequence 來處理消息觀察，從而移除對非結構化任務的依賴并避免引入額外的 ObservationToken。
- 關于 ObservationToken：
當前 ObservationToken 用于支持快速注銷觀察者，但需要明確在未調用 removeObserver 的情況下，觀察者何時被自動取消注冊。
提議將 ObservationToken 設計為 ~Copyable 類型，以確保其僅能使用一次并防止被意外丟棄。
總結：該提案為并發通知管理帶來了重要改進，但仍有設計細節需要完善，例如協議的約束合理性、API 的性能及安全性優化，以及觀察者生命周期管理的明確性。
- 討論隨機“Clock”持續時間[5]
用戶嘗試實現一個函數，基于通用 Clock 生成一個從零到指定上限的隨機持續時間 (Duration)。由于 Clock.Duration 僅受限于 DurationProtocol，直接實現這一功能存在挑戰。幸運的是，Swift.Duration 提供了 seconds 和 attoseconds 兩個 Int64 組件，可以通過組合它們生成一個隨機的 Int128 值（Swift 6 中新增支持），實現隨機持續時間計算。
extension Clock where Duration == Swift.Duration {
func randomDuration(upTo maxDuration: Duration) -> Duration {
let random = Int128.random(in: 0..<(Int128(maxDuration.components.seconds) * 1_000_000_000_000_000_000 + Int128(maxDuration.components.attoseconds)))
return Duration(secondsComponent: Int64(random / 1_000_000_000_000_000_000), attosecondsComponent: Int64(random % 1_000_000_000_000_000_000))
}
}關鍵問題與討論：
- 通用性限制：
此實現僅適用于 Duration 為 Swift.Duration 的時鐘，不適用于其他 DurationProtocol 實現。用戶希望找到更通用的方法。
- 非均勻性與運行時性能：
有人指出該方法可能具有非均勻的運行時，且在理論上可能出現運行時間非常長的情況。
然而，在實際應用中，這種情況極少發生。例如，使用簡單的拒絕采樣算法時，97.5% 的情況下只需一次采樣，99.95% 的情況下兩次采樣即可完成。因此，這種“不均勻性”在實際意義上幾乎可以忽略不計。
- 效率與可行性：
盡管方法在某些情況下理論上不夠優雅，但其實際運行效率足夠高，對絕大多數應用場景而言是合理的解決方案。
總結：該方法利用 Swift.Duration 的組件生成隨機持續時間，但受限于特定類型的 Clock，不夠通用。此外，盡管存在理論上的非均勻性問題，但在實踐中這種方法的效率和可靠性可以滿足需求。進一步優化可能需要考慮更通用的 DurationProtocol 支持，以及潛在的性能改進方向。
- 討論withCheckedContinuation(isolation:function:_:) 中的 SIGSEGV[6]
團隊在將代碼庫遷移到 Swift 6 語言模式 時，發現使用 withCheckedContinuation(isolation:function:_:) 的網絡接口與基于 Combine 的任務發布器同時支持的實現，在遷移到 Xcode 16 后，出現了一些 tvOS 18.0 上的崩潰問題。以下是問題描述與社區反饋總結：
問題概述：
- 崩潰日志指向 withCheckedContinuation(isolation:function:_:) 函數，相關調用棧位于 swift::runJobInEstablishedExecutorContext。
- 該問題出現在 Xcode 16 及其后續版本（如 16.1），影響從 iOS 18 開發者測試版 1 至 4 的客戶端。
- 崩潰的根本原因與并發全局函數（如 withThrowingTaskGroup、withCheckedThrowingContinuation）在引入 isolation 參數后的行為變化相關。
社區反饋與應對建議：
- 升級與回滾策略：
建議升級至 Xcode 16.1：盡管某些問題依舊未解決，但部分用戶報告升級后穩定性有所改善。
回滾到 Xcode 15.4：因 Xcode 16 在特定環境中的兼容性問題，一些團隊選擇回滾以降低崩潰率，盡管開發人員在升級后可能難以回退。
- 直接修復方法：
將 stdlib 中的崩潰函數直接復制到本地并進行調整（通過復寫方式規避問題）。此方法在部分生產環境中已穩定運行數周。
對外部依賴的適配方法：
如果依賴庫是預構建的，可以嘗試修改符號引用以指向本地修復版本。
注意避免全局替換定義（如使用 @_dynamicReplacement 或類似 fishhook 的動態鏈接庫替換工具）。
- 對每個函數問題的單獨解決：
相關函數：包括 withThrowingTaskGroup、withCheckedThrowingContinuation、withCheckedContinuation 等。
獨立處理的必要性：這些函數引發崩潰的原因相似，但解決方法可能需要針對每個函數的具體實現進行單獨的調整。
- 函數定義與參數順序的影響：
某些函數（如 TaskLocal.withValue）雖然也添加了 isolation 參數，但因參數順序不同而避免了崩潰。例如：
當 isolation 被解釋為其他類型（如 String）且未被函數主體讀取時，崩潰未發生。
而 withCheckedContinuation 將 isolation 放置在閉包之前，導致其嘗試將傳入的隔離上下文作為閉包使用，從而引發崩潰。
總結：該問題源于并發函數在 Swift 6 中的實現變化，對特定上下文的兼容性不足。盡管有升級工具鏈的建議，但實際生產中需依賴本地修復和對依賴庫的定制適配。此外，函數參數順序設計和隔離上下文的解析方式也是影響崩潰的潛在原因。開發者需在遷移到 Swift 6 或 Xcode 16 時進行充分測試并實施必要的兼容性修復。
- 提議SE-0453：向量，固定大小的數組[7]
Swift 論壇對提案 SE-0453: Vector（固定大小數組） 的首次評審已開啟，將持續至 2024 年 11 月 27 日。本次評審專注于類型的 API 表面和基本行為，暫不討論名稱 Vector 的相關反饋。后續評審會專門討論命名問題。
提案概述：
提案引入了固定大小的 Vector 類型，其特點是：
- 固定大?。阂坏﹦摻?，大小不可更改。
- 完全初始化：所有元素必須在初始化時完成初始化，不能動態添加或移除元素。
- 非可復制性（潛在特性）：雖然 Vector 可能不可復制，但其主要獨特性在于其固定大小和初始化需求。
核心反饋與討論：
- 初始化的特殊性：
與其他數據結構不同，Vector 無法通過常規方法（如 init()、reserveCapacity()、append()）操作，因此初始化器需要支持直接生成元素集合。
提案中的初始化器適合 Vector 的獨特性，但可能仍不足以覆蓋更復雜的初始化模式。
- 關于通用初始化器的建議：
當前的初始化器雖然足夠實用，但建議引入更底層的初始化方法，類似于 Array 的 init(unsafeUninitializedCapacity:initializingWith:)，允許開發者通過 UnsafeMutableBufferPointer 手動初始化。
一個更安全的方案是引入一個閉包初始化器，按元素順序初始化，同時提供對已初始化元素的訪問（例如通過未來可能支持的 Span 或 MutableSpan 類型）。這種方法可以讓初始化過程利用已有元素，實現排序、打亂等操作。
- 適配性與靈活性：
提案的初始化器被認為過于具體，可能限制開發者實現更復雜的功能場景。設計更通用的基礎功能有助于提升 Vector 的適配性。
總結：
提案為 Swift 引入了一個高效的固定大小數組類型，適用于需要確定大小且不可變的數據場景。然而，初始化器的設計需要進一步討論，以支持更多復雜的模式和用例。評審社區還需探討是否應該提供更通用的底層功能來滿足多樣化需求。
- 提議修改和讀取訪問器[8]
論壇中，針對提案 修改和讀取訪問器 的討論主要集中在訪問器的命名、語義區分以及潛在的未來擴展。以下是提案要點與社區反饋的總結：
提案要點
- 目標版本與時間表：
該提案未計劃納入 Swift 6.1，即使在接近的分支切割時間（2024 年 11 月 13 日）后，也不會立即生效。
- 是否支持 async 訪問器：
當前提案未引入異步訪問器（如異步 read 和/或 modify）。
提到這是未來可能探索的方向，同時需要考慮與現有功能的痛點進行整合。
- 命名建議：borrow 和 mutate 替代 read 和 modify：
提案計劃將 borrow（借用）和 mutate（變更） 用于更加基礎的訪問器，這些訪問器提供對 self 組件的直接借用或可變借用。
而 read 和 modify 更適合描述基于協程（coroutine）的訪問器行為，它們強調操作的臨時性和持續時長。
- 語義區分：
get 和 set：
表示訪問器的瞬時性和最終性，傳遞數據的所有權，而無需持續的操作。
read 和 modify：
強調活動的持續時間，為某一實體提供臨時直接訪問權限，而非所有權轉移。
舉例：讀取朋友的表情或讓鎖匠修改前門，均是具有開始和結束時間的活動，不涉及對象所有權轉移。
- 未來方向：投影訪問器（Projection Accessors）：
投影訪問器可返回與基礎對象等長的借用值，使用borrow 和 mutate更符合其語義。
此類訪問器能拓展當前存儲屬性的語義，并為 Swift 提供更靈活的借用模型。
反饋與討論
- 關于詞匯選擇的細致區分：
社區成員建議 borrow 和 mutate 是否能替代 read 和 modify，但提案認為它們有顯著的語義差異：
read 和 modify 強調基于協程的臨時性與操作持續時長；
borrow 和 mutate 則適合表示直接的內存借用。
- 詞義對比與命名合理性：
提案反駁了將 read 視為 get 同義詞的觀點，強調了兩者的語義細微差異。
參考詞典，read 和 borrow 或 modify 和 mutate 并非嚴格同義，且其語境含義差異足以避免長期混淆。
- 生命周期與類型安全性：
基于協程的 read 和 modify 訪問器，其操作對象僅在訪問期間物化，不適合用于建模包含關系（containment）。
在處理非可逃類型（non-escapable types）時，這種差異會影響生命周期語義，成為至關重要的問題。
總結:
提案中的命名設計從語義、生命周期管理與未來擴展性等角度出發，避免了簡單的詞匯替換以確保語義精確性。當前提案專注于基礎訪問器功能，但也為未來的功能（如異步訪問器與投影訪問器）留出了擴展空間。
