ქეში

გადაამუშავეთ ბილდის არტეფაქტები თქვენს გუნდსა და CI-ში ერთნაირი კოდის ხელახალი კომპილაციის თავიდან ასაცილებლად

გამოთვლა

გაუშვით რანერები წამებში და დაამასშტაბირეთ თქვენს გუნდთან და აგენტებთან ერთად

ტესტები

შეამოწმეთ მხოლოდ ის, რაც შეიცვალა და ავტომატურად აღმოაჩინეთ არასტაბილური ტესტები

Previews

გაუზიარეთ თქვენი აპლიკაცია მყისიერად URL-ით — დააჭირეთ და გაუშვით ნებისმიერ მოწყობილობაზე

შექმნილი პროექტები

გაამარტივეთ მოდულური Xcode პროექტები უფრო მარტივი შენარჩუნებისა და მასშტაბირებისთვის

რეგისტრი

ჩამოტვირთეთ მხოლოდ ის, რაც გჭირდებათ — უფრო სწრაფი და მსუბუქი ბილდები ადგილობრივად და CI-ზე

შესახებ

გაიგეთ მეტი Tuist-ის შესახებ და გაეცანით გუნდს

საჯარო დაფა

გაეცანით Tuist-ის ფუნქციებს საჯარო დაფაზე

მომხმარებლები

ნახეთ, როგორ ზრდიან წამყვანი გუნდები პროდუქტიულობას Tuist-თან ერთად

Slack

შეუერთდით საზოგადოების Slack-ს

ნიუსლეტერი

იყავით ინფორმირებული - გამოიწერეთ ჩვენი სიახლეები

GitHub

ჩვენს წყაროები, საკითხები და PR-ები

საზოგადოების ფორუმი

შეუერთდით დისკუსიებს და გაუზიარეთ იდეები ჩვენს საზოგადოების ფორუმზე

ცვლილებების ისტორია

added

Export build history with filters and stable pagination

The Xcode build list API now supports date ranges, CI filtering, and cursor pagination for exporting build history to tools such as BigQuery. Use from and to Unix timestamps to select an inclusive creation-time range, and is_ci=false to focus on local builds.

Follow pagination_metadata.end_cursor with after to fetch older builds without new uploads shifting page boundaries. Use before with start_cursor to navigate back. Pages can contain up to 1,000 builds. Existing clients keep their first-page metadata and offset pagination. The initial response also includes cursors: omit page and pass after or before to continue with stable cursor pagination.

Build list and detail responses also include started_at, the actual build start recorded in newly processed activity logs. This is separate from upload time (inserted_at) and stays null for historical builds or reports without a recorded start time.

added

Elixir dependency caching

Tuist's Elixir integration can now reuse compiled dependencies through the same Kura REAPI cache as Bazel. Enable it with cache: true and the compile alias to automatically select supported dependencies. Declare additional compile-time inputs or exclude dependencies with non-deterministic compilation when needed. An input key maps to an ActionResult referencing a content-addressed dependency compilation bundle; clean builds can restore it without compiling that dependency again. Authentication, endpoint discovery and signed cache analytics use the existing shared APIs.

The Mix Cache page follows Xcode's layout, showing average and percentile build hit rates above Recent Builds. Transfer, latency and throughput retain real measurements and local-copy/remote-CAS provenance; legacy values stay unavailable rather than zero. Each build's Mix cache tab has task hits, misses, hit rate and download/upload totals, a lookup breakdown, latency percentiles and searchable task rows with copyable keys and Xcode-aligned CAS-only expanded rows. Expand tasks to follow their actual bundle hashes into CAS Outputs, whose graph, download/upload throughput and output table use Bazel's shared REAPI queries over Kura-signed records. Local copies never become invented remote output rows. Bypassed and already-current dependencies do not count as misses; avoided compilation time is an estimate, not elapsed build savings.

Caching remains opt-in and dependency-only. Unsupported native/custom compilation falls back to Mix. A verified local snapshot store covers unavailable remote endpoints, authentication and storage failures without hiding compiler errors. Checkout paths participate in keys by default; portability requires explicit opt-in because BEAMs can retain producer paths. Compilation bundles can also embed compile-time values, so audit selected dependencies and project cache access. See the Elixir cache guide for configuration and safety limits.