This discussion was recorded in 2022. The guests’ work situations, technical choices, and impressions of the market belong to that time. Their forecasts about headsets, cars, and the replacement of technologies remain their views and points of disagreement.
How does a developer assess a WWDC after returning from Apple Park? The answer may not begin with an API. On Day 2, Daozhang and Lao Lu first described something that fell short of their expectations: after traveling to attend the special event, they still watched the principal presentations on video. From there, the conversation moved through the campus, earlier conferences, and their careers before turning to new devices, in-car interfaces, and the opportunities available to independent developers.
Ye Da and Zheng Yidong helped host a conversation that held more than one feeling at once. The guests admired aspects of Apple’s design and integration across hardware and software while questioning the event experience, the pace at which new technology might reach users, and the shape of future work. The recording is more informative when those mixed reactions remain intact.
From Swift to the art of a keynote: What developers remember
The hosts opened with memories of earlier Apple presentations. The group discussed the way product launches built a story, the iPhone 4’s design, and the shock of Swift’s announcement in 2014.
For Lao Lu, Swift was more than a change of syntax. Developers who had long written Objective-C suddenly encountered more modern language features and a fresh set of problems worth learning and debating. The Chinese-language community that grew around Swift is closely tied to that technical shift. Different speakers remembered different years, but they shared a point: one conference can shape the next several years of work, and sometimes prompt a new community to form.
Daozhang recalled an early Macintosh presentation in which the computer spoke for itself. Lao Lu brought up the iPhone 4 and the industry’s reaction to Swift in 2014. Ye Da added that, when he later revisited the original iPhone launch, the reveal that several advertised products were one device helped him understand why presentation matters. This was not nostalgia alone. When a new language, interaction model, or tool appears, developers must decide almost immediately what to learn and how it might change their projects.
One host admitted that he once thought of WWDC mainly as a product launch. He later came to see the many days of engineering sessions and API material behind the public presentation. That distinction runs through the episode: a keynote makes a change legible to a broad audience; the developer sessions show how to put it to work.
The discussion of presentation style kept returning to a practical question: how can an audience understand something quickly? A vivid analogy, an expectation followed by a reveal, or a technology placed in a recognizable situation can last longer in memory than a list of specifications. The guests also recalled dates, market-share figures, and industry stories without checking them during the show. Their figures and claims about firsts remained unverified. The original iPhone launch was a different event, not a WWDC segment.
The group then considered the attraction of Apple’s ecosystem. Guests described trying other devices yet continuing to value the connections among the systems they used. Those are personal experiences as users and developers, not purchasing advice for everyone. Professionally, they were interested in whether an ecosystem could keep generating jobs, tools, and product opportunities. That question prepared the ground for the second half of the program.
At the venue, why were they still watching a video?
The conversation returned to the WWDC22 event the two guests had just attended. Daozhang compared it with his earlier experiences. The Apple Park staff were welcoming, the audience expected to see new material, and there was an opening greeting. Yet the main presentations were prerecorded videos.
His account was specific. He expected the introduction onstage to lead into a live keynote. After Tim Cook’s brief greeting, however, the crowd continued watching a video outdoors. Both guests recognized that a produced film could achieve camera work and effects unavailable to a conventional live presentation. A long trip and an outdoor screening nonetheless changed the relationship between being present and receiving exclusive information. Lao Lu asked whether, if the announcement itself was all he wanted, he might have been more comfortable watching from home.
Daozhang also remembered staff guiding people to their seats, the stage and camera equipment raising the crowd’s hopes, and the physical experience of sitting in the sun for a long screening. Lao Lu thought of developers arriving from countries such as France and the United Kingdom: free admission did not erase the cost of international travel and time. Their criticism concerned what an attendee gained by making the journey, not a denial that meeting people there had value.
Lao Lu felt the gap between his expectation and the event, too. Travel, time-zone changes, and sitting outdoors all carried costs. He thought in particular of developers who had come from other countries and asked what additional value the trip could offer them.
In its April 2022 announcement, Apple had already described the special Apple Park event as a shared viewing of the Keynote and State of the Union videos. The format was public, yet the two guests still experienced a gap between their expectations and what being there felt like.
The value of being there therefore lay beyond the video: entering the campus, speaking with other developers and Apple staff, feeling the atmosphere, and joining the related tours. If the goal was only to hear what was announced, travel might not be necessary. If those conversations and observations mattered, the calculation changed. Informal remarks from staff about possible future formats were not Apple’s official plans.
Lao Lu broke the day into a shared morning viewing of the keynote, an afternoon platform overview, a campus tour, and activities connected with the design awards. Compared with earlier in-person conferences that offered several days of sessions, this was a one-day special event; the technical sessions remained online. Daozhang valued conversations with Apple employees, while recognizing that informal comments about the future were not an official plan.
Lao Lu also described the newly opened Developer Center, including spaces for meetings and exchange, a stage, and facilities associated with recording. He said he did not then know all its access rules. His account tells us what he saw and what uses he imagined. It does not establish today’s booking conditions, prices, or general public access.
What kind of environment sustains a long development career?
An audience quiz about the early MacBook Air led to a longer question: why can some technical infrastructure accumulate over many years, and what allows someone to keep developing software for decades?
The guests connected infrastructure with people’s accumulated experience. Joining an organization with mature tools, processes, and systems provides a different starting point from building every layer from scratch. It is easy to see the polished output; the years underneath require more patience to recognize.
The quiz provided a small example. The audience quickly recalled the early MacBook Air being presented inside a paper envelope. A host used that lightweight reveal to talk about the work hidden behind a mature system. Lao Lu then shifted from technical infrastructure to career conditions. He had met people still writing applications in their forties and fifties, and argued that continued interest and expertise also depend on whether an organization offers senior developers paths for growth that do not all lead to management.
The discussion touched on age and career choices. Some worried that, in their own work environments, developers faced pressure to move into management comparatively early, or needed to find a more specialized technical direction to keep progressing. Another observation from the event was that older developers can still build applications and even take up a new technology midway through their careers. A long career need not be confined to low-level research.
Each speaker drew on a different workplace and career. Some felt pressure to move into management early; others had met application developers still working in their forties and fifties. No shared rule emerged that application development becomes impossible at a certain age. Their underlying question was whether a person can keep building on what they have learned instead of having that experience reset every few years.
AR and VR: An interaction model matters more than a new name
The hosts divided the future-facing conversation into device form factors, the rumored “Reality OS,” cars, and opportunities for individuals. The first two were hopes and speculation in this recording, not descriptions of products announced at WWDC22.
Lao Lu began with the device itself. If a device moves from the hand to something worn or carried continuously, the interaction between person and computer changes. Processing power, heat, battery life, and size jointly determine whether that experience can work. A picture of an interface is not yet a usable product.
His imagined headset showed how those limits interact. More mobile computing power can create pressure on heat and battery life, while a smaller body leaves less room for either batteries or cooling. He spoke of an almost full day of use as a personal hope, then reasoned that an SDK would have to give developers preparation time ahead of hardware. This was a way to assess whether an ecosystem could form, not a specification for an announced device.
He added an ecosystem argument: developers would need tools and preparation time before a new hardware platform could support many applications. That helps explain why some participants expected an operating system or SDK at the conference. Claims about a delay, supply chains, and precise timing were rumors circulating then, with no confirmed release schedule.
Ye Da asked for a more basic use case. He had tried headsets, but still did not know what he would put one on to accomplish every day. Lao Lu listed the constraints of size, cooling, battery life, and mobile computing. Daozhang added that AR must relate virtual content to the real environment, including occlusion and spatial relationships. That is a different design problem from organizing games, entertainment, or social experiences entirely within a virtual environment. The group did not find an instant use case, and a technical capability cannot decide a product’s purpose by itself.
The host pressed the point: beyond briefly entering an immersive scene, what would someone actually do in ordinary life? The guests distinguished fully virtual experiences from information layered over the surrounding world. The latter must address not only space and occlusion but sound and interactions with physical objects.
Ye Da said he had tried the headsets of the time without finding a reason to wear one every day. Daozhang used the question to separate games or social spaces built wholly in a virtual world from information overlaid on the surroundings. In the latter, real objects must occlude virtual ones correctly, and sound must reflect distance and position. Some saw a complete virtual environment as comparatively easier to construct, while others noted that entertainment and social activity could themselves be substantial needs. Their disagreement concerned the activity to serve, not which label was more advanced.
The guests also discussed room scanning and modeling. Apple’s WWDC22 RoomPlan session describes the related API available at the time. Its existence did not establish how an imagined future pair of glasses would implement spatial features.
The discussion moved on to rendering, networks, and latency. The guests expected high-quality, real-time immersion to put pressure on the underlying system, citing resolution and low delay as examples. The network and display requirements vary with local rendering, streaming, display configuration, and content; no single threshold describes every VR product.
A CarPlay preview is not a roadmap for an Apple car
From headsets, the group turned to cars. Lao Lu thought that, were Apple to enter the field, its software, ecosystem, and overall experience might be more interesting to watch than mechanical manufacturing. Daozhang first reviewed the next-generation CarPlay preview at WWDC22: several displays, instrument information, vehicle controls, and personalized interfaces.
There is an important date boundary here. Apple’s 2022 announcement called next-generation CarPlay a preview and said vehicle announcements would begin late the following year. It was not a guarantee that every feature would be manufactured and delivered by the end of 2023, or that drivers could immediately enable it in every car.
The guests saw several degrees of possible cooperation between a technology company and carmakers. Some partnerships could connect a phone to an in-car system; others could reach more deeply into the vehicle platform. This led to an open question: is supplying software with a carmaker the same decision as manufacturing a whole car? They urged caution about staking years of development on a project that had not been confirmed merely because a keynote showed a compelling interface.
Daozhang recalled the preview’s instrument cluster, multiple screens, cabin-temperature controls, and personalized components, and compared partnerships involving some carmakers and Android Automotive. The same manufacturer might work with more than one technology platform. Behind the demonstration, he reasoned, lay questions about interfaces, data, safety, and business agreements. Lao Lu, approaching the subject from another angle, saw software and experience as closer to Apple’s strengths than mechanical production. Neither treated the CarPlay partner list as evidence that Apple would build its own vehicle.
The guests had no answer to whether Apple would make a car, what supply chain it might use, or when it might offer new jobs. They left opposing possibilities on the table: continued cooperation with carmakers or a later strategic shift. A developer could first separate announced software capabilities from unknown business plans before choosing how much personal time to invest.
New APIs and independent apps: Different costs of experimenting
The host brought the question back to an individual developer. Does each new set of system capabilities create another opening for independent apps? He could point to products that had grown around earlier system entry points, but after watching that year’s updates he had not found an especially certain idea of his own.
Daozhang first distinguished organizations. A team with substantial existing business, users, and historical code must consider stability, maintenance, and delivery. A newly announced API does not automatically belong in that product. His experience of a former team’s cautious adoption of Swift illustrated why a commercial team cannot take on migration costs merely for novelty. It was a judgment drawn from one setting, not a rule that every company must wait a fixed number of years.
One team Daozhang had known still maintained its product largely in Objective-C several years after Swift arrived. The reason was not that no one understood the newer language. The existing code met the business need, while a migration required fresh decisions about stability, dependencies, and long-term maintenance. Lao Lu added another side: if an API provides a new entry point for existing consumer apps, it may first improve those products without creating a whole new kind of demand. Learning a framework and discovering a product worth operating for years are separate questions.
Independent developers and small teams may have fewer such constraints. They can choose a newer minimum OS version, test a narrower use case, and more readily try tools such as SwiftUI. Yet a convenient implementation tool does not create demand. Lao Lu offered another caution: many kinds of consumer app already had numerous competitors, and a new API might improve an existing experience rather than establish a new product category. Sometimes a genuinely new space also requires a change in device form or user habit.
Daozhang again used a large team he had known as an example: a new language could exist while the team kept older technology for stability and maintenance. A small team might try SwiftUI early or design for a new system release, while accepting a smaller device audience. Lao Lu observed that startup discussions at the time often turned toward enterprise services, whereas a consumer API might first make established products better. The contrast was about the cost structure of experiments, not a claim that large companies necessarily fall behind or small teams necessarily win.
Neither guest supplied a list of the next breakout applications. The absence of certainty is part of the 2022 record. Developers watched new capabilities while worrying about room for growth in mobile apps. They hoped for another platform opening but did not want to treat rumor as a career guarantee.
An opening audience activity offered a smaller, more concrete idea: show the progress of a requested ride on the lock screen. It was a community suggestion, not proof that a product had shipped successfully. It points toward a workable way to evaluate a new entry point: start with the real irritation of waiting, checking, and switching screens, then ask whether the new interface makes that existing task easier.
Questions at the end: SwiftUI possibilities and the physical campus
The final questions did not make the earlier uncertainty disappear. Daozhang continued discussing developer opportunities. SwiftUI’s cross-platform reach, charts, and layout tools led him to imagine how it might extend to additional screens.
His ideas about the framework that might power future in-car interfaces, or whether SwiftUI might gradually replace other interface technologies, remained personal extrapolations. They were not evidence of an Apple-confirmed internal CarPlay architecture, and did not mean UIKit was already obsolete. What the recording preserves is his observation that Apple was extending a more unified development experience across devices, giving developers reason to watch its cross-platform tools.
Daozhang explained his inference. Instrument panels, widgets, and multi-display combinations in the preview appeared to have repeatable layout structures, while SwiftUI had gained charts, layout tools, and cross-device capabilities that year. He guessed it could express that kind of interface. The reasoning may help a developer evaluate a tool, but it cannot stand in for public architectural documentation. Even a visually predictable interface must deal with vehicle data, safety, and manufacturer integration.
Lao Lu answered a question about the campus. The visitors could enter specified areas, not wander freely through all of Apple Park. Glass, even wall surfaces, integrated fixtures, landscaping, and an orderly sense of space conveyed design consistency to him. The building’s scale also meant long walks. Those observations explain the experience more clearly than simply calling the place beautiful.
He singled out the appearance of glass in strong light, mountains visible in the distance, and equipment set into smooth walls. The large open center made a strong visual impression but increased the walk from one side to the other. He was answering what the visitors actually saw and where they went, not reviewing the operational efficiency of the whole campus.
The two answers gave the episode two scales: one imagined future screens through developer tools; the other examined an actual space through observed details. Their evidence is different. A visitor can describe the area they saw. A future technical direction must remain a question.
The program ended by thanking guests who joined across time zones and previewing later practical sessions from Laosi Ji Technology. The giveaways, channel phrases, and live schedule belonged to 2022 and have ended. The discussion remains valuable as a record of how developers formed judgments at the time.