Architecture Evolution and Efficiency Improvements of the Anjuke iOS App under the “Jupiter Plan”
The article details how the Anjuke iOS client was transformed into a platform‑shared architecture through the “Jupiter Plan”, describing background challenges, multi‑endpoint reuse, shell project separation, build‑speed optimizations, and supporting tools that together boosted development efficiency.
Background Anjuke’s business spans new homes, second‑hand homes, rentals, commercial and overseas real estate, with additional modules such as large‑content, user center, and IM. Rapid growth in 2019 required higher technical support to maintain stability, improve multi‑entry development speed, and evolve the app architecture.
To address these needs, the "Jupiter Plan" was launched jointly with 58 Wireless, 58 Real‑Estate, frontend and backend teams, unifying the underlying architecture of Anjuke and 58 apps and completing componentization so that a single codebase could be deployed on both platforms.
"Jupiter Plan" Evolution Initial code copying quickly revealed insufficient manpower to sustain the business line, prompting a full architectural upgrade. The goal became "multi‑endpoint reuse" – a single codebase running on both Anjuke and 58 apps, effectively doubling development efficiency.
1. Current State Analysis Differences between the two apps included inconsistent third‑party library versions, divergent business logic, and incomplete componentization, leading to duplicated effort and maintenance overhead.
2. Multi‑Endpoint Reuse The solution extracts shared business code into independent Pods, which are then referenced via Podfiles and Podspecs, enabling the same functionality to be used across both apps while keeping underlying services (IM, maps, networking, routing) consistent.
3. Shell Project Separation The original monolithic shell project was split into an empty shell containing only configuration and dependency files, turning internal components into private Pods. This clarified responsibilities, facilitated future binary distribution, and aligned the Anjuke development environment with 58’s.
4. Build Speed Optimization Several bottlenecks were addressed:
Git clone speed improved by linking Pods locally and reducing repository size.
Resource copying during compilation was made optional for unchanged assets, cutting unnecessary copy time.
Source compilation time reduced by offering binary Pods, limiting builds to armv7, and removing dead code.
The following Ruby hook was added to skip resource copying when appropriate:
def no_copy_resources_if_needed(pod_installer)
pod_installer.aggregate_targets.each do |target|
copy_pods_resources_path = "Pods/Target Support Files/#{target.name}/#{target.name}-resources.sh"
copy_sh_text = File.read(copy_pods_resources_path)
no_copy_resources_sh = "#!/bin/sh \nif [[ \"$noCopyPodResources\" == \"YES\" ]] && [[ \"$CONFIGURATION\" == \"Debug\" ]] && [ -f \"${BUILT_PRODUCTS_DIR}/Assets.car\" ]; then \n\t echo \"No need to copy Pods images and XIB resources. Remove YES from noCopyPodResources to force copy.\"\n\t exit 0 \nfi \necho \"CocoaPods is processing assets...\"\n"
new_contents = copy_sh_text.gsub('#!/bin/sh', no_copy_resources_sh)
File.open(copy_pods_resources_path, "w") {|file| file.puts new_contents }
end
end5. Tooling Additional utilities were built:
Git‑repo helper to generate private tokens, create merge requests, and handle multiple repositories.
Packaging platform enhancements to produce both Anjuke and 58 test builds simultaneously, reducing QA turnaround.
Link‑map analysis for package size, and Fastlane integration for iOS CI/CD.
Summary & Outlook By modularizing the shell, adopting multi‑endpoint reuse, and optimizing build pipelines, the team significantly reduced compilation time and improved developer productivity. Future work includes deeper compilation caching, incremental builds, and further component isolation as the product ecosystem expands.
58 Tech
Official tech channel of 58, a platform for tech innovation, sharing, and communication.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.