Apple increases investment to lift iPhone 16 ban

Preface

This is the 66th weekly report compiled independently by the Swift editorial team. Each module has taken shape.

The Swift Weekly Report is open source on GitHub [1]. We welcome you to submit issues, contribute or recommend content. We plan to publish it every two weeks on Monday. We welcome like-minded friends to join us in compiling the weekly report.

If you decide to be brilliant, there is nothing to block you, no mountains to block you, no sea to block you. The Swift community will use black and white eyes to observe the colorful world with you! 👊👊👊

Weekly Highlights

News and Community: Apple’s $100 million investment still can’t lift the iPhone 16 ban?

Proposal: SE-0453: Vectors, Fixed-Size Arrays proposal is under review.

Swift forums: Proposal to modify and read accessors

Recommended blog post: Generation and use of Swift Intermediate Language (SIL)

Topic discussion:

What do you think about the rapid development and growth of AI technology?

Previous topic results

picture

The voting results show that people are still rational about consumption. Capital’s tricks are no longer effective.

News and Community

Apple’s $100 million investment still can’t lift the iPhone 16 ban?

November 22, 2024

The latest smartphone of US technology giant Apple, the iPhone 16 series, encountered difficulties in the Indonesian market shortly after its launch. Apple is currently seeking to lift Indonesia's ban on the sale of iPhone 16.

The ban stems from the fact that Apple's products in Indonesia failed to meet the 40% localization requirement and did not obtain permission to be sold in the country. The ban is intended to protect local industries and jobs.

Previously, Apple had proposed solutions twice. Initially, it planned to invest nearly 10 million US dollars in the local area to expand the production line. The Indonesian officials did not respond much. A few days later, Apple again proposed to invest nearly 100 million US dollars in Indonesia within two years. Although Indonesia responded, Apple executives failed to meet with the country's Minister of Industry after flying to Jakarta.

According to Indonesian local media reports on Friday (November 22), the country's Ministry of Industry met with Apple representatives on Thursday (November 21) to discuss Apple's proposal to invest US$100 million over two years. It is reported that the funds will be used to invest in a research and development center project and professional development academy in the country. Apple also plans to produce accessory product components locally from July 2025, specifically for Apple's AirPods Max.

Although Apple's new offer is 10 times the previous plan, the Indonesian government expects Apple to add a little more to the $100 million investment in exchange for the lifting of the iPhone 16 ban and more access.

“Of course, from the government’s point of view, we would like the investment to be bigger,” Febri Hendri Antoni Arif, a spokesman for the Industry Ministry, said in an interview on Thursday.

He said larger investments would help develop Indonesia's manufacturing sector, adding that domestic industry was capable of supporting production of Apple products such as chargers and accessories.

Le Xuan Chiew, an analyst at Canalys who focuses on Apple strategies, said that while Indonesia is a small market for Apple, it also offers growth opportunities because it has the world's fourth-largest population.

He noted that the young, tech-savvy population with increasing digital literacy is consistent with Apple's strategy to expand global sales, while the country also offers manufacturing and assembly potential, supporting Apple's efforts to diversify its supply chain.

He also added that success in this market requires a long-term strategy, and Apple's investment demonstrates its commitment to complying with local regulations and paves the way for future growth. (Source: Cailianshe)

Apple is reportedly evaluating a new TV category, with smart home being the key

November 22, 2024

Technology media MacRumors published a blog post yesterday (November 21), citing a revelation from Bloomberg's Mark Gurman, saying that Apple is internally evaluating the idea of ​​designing and manufacturing an "Apple-branded TV" to further expand its smart home ecosystem.

It is reported that Apple is actively exploring new sources of revenue and accelerating its smart home strategy. The media believes that Apple's smart home products have been successful and TV products may appear on its future product roadmap.

Media reports that Apple will launch smart TVs can be traced back to 2006, and a former Apple executive claimed in 2011 that Apple had reached an agreement with a TV manufacturer, and the news has intensified since then.

When talking about TV, Jobs once revealed: "I finally got it. I want to create a completely easy-to-use integrated TV that can be seamlessly integrated with iCloud, and users don't have to fiddle with complicated remote controls."

Related news is known to continue until 2015, when The Wall Street Journal reported that Apple had abandoned plans for an Apple-branded TV "a year ago."

Apple launched its Apple TV+ service in November 2019 and has continued to add new TV shows and movies over the past five years. Apple TV+ now has a considerable amount of content, in addition to services such as Apple Music, which can build a complete TV ecosystem.

In terms of hardware, although the TV market is still dominated by Samsung, LG and Sony, Apple has been researching cutting-edge display technology. The media believes that Apple can still attract a large number of consumers by launching TV products now. (Source: IT Home)

Billie Eilish Named Apple Music Artist of the Year 2024

November 21, 2024

Apple today announced Billie Eilish as Apple Music’s Artist of the Year, celebrating the singer-songwriter’s extraordinary impact throughout 2024.

In this year, Billie first won a historic second Oscar and two Grammy Awards for her theme song "What Was I Made For?" written and sung for Greta Gerwig's film "Barbie", and then released her third album "HIT ME HARD AND HIT ME SOFT". This sincere and bold album represents a major leap forward for this outstanding artist of the times and is also the best work of her musical career to date. Upon its release, this album topped the Apple Music All-Gen Album Chart in 138 countries and regions around the world.

Since then, Billie has continued to make a cultural impact. In August, she represented her hometown of Los Angeles at the closing ceremony of the Paris Games, performing "BIRDS OF A FEATHER" and setting a personal record for Shazam searches that day. Billie also collaborated with Charli xcx on this summer's hit single "Guess". Her sold-out HIT ME HARD AND SOFT tour is currently underway, and will continue this year's success into 2025.

This year, Billie received seven Grammy nominations, including Record of the Year, Album of the Year, and Song of the Year. At the same time, she also became the first winner of Apple Music Artist of the Year twice - she was elected the first Apple Music Artist of the Year in 2019.

This remarkable achievement not only represents Apple Music’s love for Billie’s work, but also reflects the vigor and persistence of her creative energy. Her 2019 debut album, WHEN WE ALL FALL ASLEEP, WHERE DO WE GO?, was ranked No. 30 on Apple Music’s Top 100 Albums in May this year. The album introduced the world to a talented artist who was less than 20 years old, and HIT ME HARD AND SOFT proved that she was by no means a flash in the pan.

“We’ve been fans and supporters of Billie since we first heard Ocean Eyes nearly a decade ago,” said Rachel Newman, senior director of content and editorial at Apple Music. “It’s rare for a young artist to touch so many hearts in such a short time. We’ve been amazed by her evolution over the past year, not only because her voice and artistry continue to resonate so widely, but because she’s done it so bravely and openly — on her own terms, on her own terms.”

“Apple Music has supported my music and artistry since day one, and I’m humbled to be recognized as Artist of the Year at this stage in my career,” Billie tells Apple Music. Now you can revisit Billie’s entire body of work in spatial audio and celebrate her extraordinary achievements. In the meantime, be sure to stay tuned as Apple Music reveals the artists and songs that will shine in 2024, listen to popular playlists, and learn more about our 2024 Editors’ Picks.

Apple plans to release a new Siri in 2026: integrating advanced large models to be more like real people

November 21, 2024

On November 22, according to media reports, Apple is developing a smarter Siri with stronger conversational capabilities, aiming to surpass OpenAI's ChatGPT and other voice services.

It is reported that the new version of Siri uses a more advanced large language model (LLM). Apple hopes that the new Siri will be able to conduct continuous conversations, respond to questions more like a human, and process more complex requests more quickly.

The new Siri is called "LLM Siri" by Apple's R&D personnel. Like the Apple Intelligence launched this year, these new features will not be immediately incorporated into next year's hardware devices. Apple currently plans to release the new version of Siri as early as 2026.

It is understood that the highly anticipated Apple Intelligence function is officially launched in iOS 18.1, iPadOS 18.1 and macOS Sequoia 15.1.

iPhone, iPad, and Mac will have a "system-wide AI writing assistant" — including Mail, Notes, Messages, Pages, and third-party apps.

According to the plan, the official version of Apple iOS 18.2 will be released in December, at which time Apple Intelligence will be officially connected to ChatGPT.

Apple users can use ChatGPT for free without creating an account, and Siri will use ChatGPT's expertise to answer user questions. (Source: Fast Technology)

proposal

Proposals under review

The SE-0452[2] integer generic parameters proposal is under review.

In this proposal, we introduce the ability to parameterize generic types over literal integer parameters.

SE-0453[3] Vector, Fixed-Size Arrays proposal is under review.

This proposal introduces a new type to the standard library Vector, which is a fixed-size array. This is similar to the classic C array T[N], C++'s std::array<T, N>, and Rust's array[T; N].

Swift Forum

• Comments to SF-0011: Concurrent Security Notices [4]

The review of Swift Foundation proposal SF-0011: Concurrent safe notifications has been opened and will last until November 19, 2024. The proposal aims to improve the handling capabilities of notifications in concurrent scenarios through new APIs and introduce the following three protocols:

• Message: Basic protocol, used to define common message structures.
• MainActorMessage: Inherited from Message, used for messages that need to be received on the main thread.
• AsyncMessage: Inherits from Message and Sendable, used to support asynchronous reception of messages.

At the same time, the proposal designs two addObserver methods to handle MainActorMessage and AsyncMessage respectively.

Key feedback:

1. Constraints on MainActorMessage:

The proposal needs to further clarify whether the post() method of MainActorMessage should be restricted to being called only in the context of @MainActor to ensure that the observing closure can be triggered synchronously.

Should clarify whether MainActorMessage allows construction in non-@MainActor contexts, but requires observation on the main thread.

2. About the necessity of AsyncMessage protocol:

It has been suggested that the Sendable requirement of the AsyncMessage protocol may be redundant and that the Message protocol could be used directly and the requirement could be met by imposing constraints on the method parameters.

If the language supports dynamic isolation in the future (such as @isolated(parameter)), it may be possible to further simplify the design through properties in the Message protocol.

3. Optimization suggestions for asynchronous message processing:

The current addObserver method uses an asynchronous observer closure, but this closure may be executed through unstructured tasks, which may easily cause performance problems. For example, too many task creation and destruction will lead to increased overhead and may even cause a denial of service attack.

It is recommended to redesign the API through structured concurrency, such as introducing AsyncSequence to handle message observation, thereby removing the dependency on unstructured tasks and avoiding the introduction of additional ObservationToken.

4. About ObservationToken:

Currently ObservationToken is used to support quick unregistration of observers, but it is necessary to clarify when the observer is automatically unregistered without calling removeObserver.

It is proposed to design ObservationToken as a ~Copyable type to ensure that it can only be used once and prevent it from being accidentally discarded.

Summary: This proposal brings important improvements to concurrent notification management, but there are still design details that need to be improved, such as the reasonableness of protocol constraints, performance and security optimization of APIs, and clarity of observer lifecycle management.

2. Discussion of random "Clock" duration [5]

The user tries to implement a function that generates a random duration (Duration) from zero to a specified upper limit based on the general Clock. Since Clock.Duration is limited to DurationProtocol, it is challenging to implement this function directly. Fortunately, Swift.Duration provides two Int64 components, seconds and attoseconds, which can be combined to generate a random Int128 value (new support in Swift 6) to implement random duration calculation.

 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)) } }

Key questions and discussions:

1. General restrictions:

This implementation only works for clocks whose Duration is a Swift.Duration, not for other DurationProtocol implementations. Users are encouraged to find a more general approach.

2. Non-uniformity and runtime performance:

It has been pointed out that this method may have non-uniform runtime and could theoretically have very long runtimes.

However, in practice, this rarely happens. For example, using a simple rejection sampling algorithm, 97.5% of the time, only one sample is needed, and 99.95% of the time, two samples are enough. Therefore, this "inhomogeneity" is almost negligible in practical terms.

3. Efficiency and feasibility:

Although the method is not elegant in theory in some cases, its actual operating efficiency is high enough and it is a reasonable solution for most application scenarios.

Summary: This method uses the components of Swift.Duration to generate random durations, but is limited to a specific type of Clock and is not general enough. In addition, despite the theoretical non-uniformity problem, the efficiency and reliability of this method can meet the requirements in practice. Further optimization may require consideration of more general DurationProtocol support, as well as potential performance improvement directions.

3. Discussion of SIGSEGV in withCheckedContinuation(isolation:function:_:)[6]

When migrating the codebase to Swift 6 language mode, the team found that the implementation of network interfaces using withCheckedContinuation(isolation:function:_:) and Combine-based task publishers supported at the same time had some crash issues on tvOS 18.0 after migrating to Xcode 16. The following is a description of the problem and a summary of community feedback:

Problem Overview:

• The crash log points to the withCheckedContinuation(isolation:function:_:) function, and the related call stack is located at swift::runJobInEstablishedExecutorContext.
• This issue occurs in Xcode 16 and subsequent versions (such as 16.1), affecting clients from iOS 18 developer beta 1 to 4.
• The root cause of the crash is related to the behavior change of concurrent global functions (such as withThrowingTaskGroup, withCheckedThrowingContinuation) after the introduction of the isolation parameter.

Community feedback and response suggestions:

1. Upgrade and rollback strategy:

It is recommended to upgrade to Xcode 16.1: Although some issues are still not resolved, some users report improved stability after upgrading.

Rolling back to Xcode 15.4: Due to compatibility issues with Xcode 16 in certain environments, some teams chose to roll back to reduce crash rates, although it may be difficult for developers to go back after upgrading.

2. Direct repair method:

Copy the crash function in stdlib directly to the local computer and adjust it (avoid the problem by duplication). This method has been running stably in some production environments for several weeks.

Adaptation method for external dependencies:

If the dependent library is prebuilt, you can try modifying the symbol reference to point to the local fixed version.

Be careful to avoid replacing definitions globally (eg using @_dynamicReplacement or a dynamic library replacement tool like fishhook).

3. Individual solutions to each function problem:

Related functions: including withThrowingTaskGroup, withCheckedThrowingContinuation, withCheckedContinuation, etc.

Necessity for separate handling: The reasons for the crashes in these functions are similar, but the solutions may require separate adjustments to the specific implementation of each function.

4. The impact of function definition and parameter order:

Some functions (such as TaskLocal.withValue) also add an isolation parameter, but the crash is avoided due to the different order of parameters. For example:

When isolation was interpreted as some other type (like String) and not read by the function body, the crash did not occur.

And withCheckedContinuation places isolation before the closure, causing it to try to use the passed in isolate context as a closure, causing a crash.

Summary: This issue stems from changes in the implementation of concurrent functions in Swift 6, which lack compatibility with specific contexts. Although there are recommendations to upgrade the toolchain, actual production requires local fixes and customized adaptation of dependent libraries. In addition, the order of function parameters and the way of parsing isolated contexts are also potential causes of crashes. Developers need to conduct sufficient testing and implement necessary compatibility fixes when migrating to Swift 6 or Xcode 16.

4. Proposal SE-0453: Vectors, fixed-size arrays [7]

The first review of the Swift forum proposal SE-0453: Vector (Fixed-Size Array) has begun and will last until November 27, 2024. This review focuses on the API surface and basic behavior of the type, and does not discuss feedback related to the name Vector. Subsequent reviews will specifically discuss naming issues.

Proposal Overview:

The proposal introduces a fixed-size Vector type, which features:

• Fixed size: Once created, the size cannot be changed.
• Full initialization: All elements must be initialized during initialization, and elements cannot be added or removed dynamically.
• Non-copyability (latent feature): While Vector may not be copyable, its main uniqueness lies in its fixed size and initialization requirements.

Core feedback and discussion:

1. The peculiarity of initialization:

Unlike other data structures, Vector cannot be operated through conventional methods (such as init(), reserveCapacity(), append()), so the initializer needs to support directly generating a collection of elements.

The proposed initializer is suitable for the uniqueness of Vector, but may still be insufficient to cover more complex initialization patterns.

2. Recommendations for generic initializers:

Although the current initializer is practical enough, it is recommended to introduce a lower-level initialization method, similar to Array's init(unsafeUninitializedCapacity:initializingWith:), which allows developers to manually initialize through UnsafeMutableBufferPointer.

A safer solution is to introduce a closure initializer that initializes in order and provides access to the initialized elements (for example, through Span or MutableSpan types that may be supported in the future). This approach allows the initialization process to use existing elements to implement operations such as sorting and shuffling.

3. Adaptability and flexibility:

The proposed initializer is considered too specific and may limit developers from implementing more complex functional scenarios. Designing more general basic functions will help improve the adaptability of Vector.

Summarize:

The proposal introduces an efficient fixed-size array type to Swift, suitable for scenarios where data of a certain size and immutability is required. However, the design of the initializer needs further discussion to support more complex patterns and use cases. The review community also needs to explore whether more general underlying functions should be provided to meet diverse needs.

5. Proposed modification and read accessors[8]

In the forum, the discussion on the proposed changes and read accessors mainly focused on the naming of accessors, semantic distinctions, and potential future extensions. The following is a summary of the proposal points and community feedback:

Proposal highlights

1. Target version and timeline:

The proposal is not scheduled for inclusion in Swift 6.1, and will not take effect immediately even after the approaching branch cut time (November 13, 2024).

2. Whether to support async accessor:

The current proposal does not introduce asynchronous accessors (such as asynchronous read and/or modify).

It is mentioned that this is a possible direction to explore in the future, and it is necessary to consider integrating it with the pain points of existing functions.

3. Naming suggestion: borrow and mutate instead of read and modify:

The proposal plans to use borrow and mutate for more basic accessors that provide direct borrows or mutable borrows of the self component.

Read and modify are more suitable for describing the behavior of coroutine-based accessors, which emphasize the temporary nature and duration of the operation.

4. Semantic distinction:

get and set:

Expresses transient and final properties of accessors, transferring ownership of data without requiring ongoing operations.

read and modify:

Emphasizes the duration of an activity and provides temporary direct access to an entity rather than a transfer of ownership.

For example, reading a friend's expression or having a locksmith modify your front door are both activities that have a start and end time and do not involve the transfer of object ownership.

5. Future Directions: Projection Accessors:

Projected accessors can return borrowed values ​​that are as long as the underlying object, and using borrow and mutate is more consistent with their semantics.

Such accessors extend the semantics of current stored properties and provide a more flexible borrowing model for Swift.

Feedback and Discussion

1. A detailed distinction about vocabulary selection:

Community members have suggested whether borrow and mutate could replace read and modify, but the proposal argues that they have significant semantic differences:

read and modify emphasize the temporary nature and duration of operations based on coroutines;

Borrow and mutate are suitable for direct memory borrowing.

2. Comparison of word meanings and rationality of naming:

The proposal refutes the view that read is a synonym for get, emphasizing the subtle semantic differences between the two.

According to the dictionary, read and borrow or modify and mutate are not strictly synonymous, and their contextual meanings differ enough to avoid long-term confusion.

3. Lifecycle and type safety:

Coroutine-based read and modify accessors, whose operation objects are materialized only during access, are not suitable for modeling containment.

This difference affects lifetime semantics and becomes a critical issue when dealing with non-escapable types.

Summarize:

The naming design in the proposal takes into account semantics, lifecycle management, and future extensibility, avoiding simple vocabulary replacement to ensure semantic accuracy. The current proposal focuses on basic accessor functions, but also leaves room for expansion for future functions (such as asynchronous accessors and projection accessors).